Re: [Vala] ListStore and SQLite

[Christian Hergert <christian hergert gmail com>]

I wrote a GtkTreeModel that fronted SQLite years ago.  I think Conduit still
uses a python prototype I made which is far more optimized than the original
prototype in C (EggSqliteStore).  It might serve as a base however to get
you started.

http://audidude.com/dropbox/egg-sqlite-store/

-- Christian

On Tue, Sep 22, 2009 at 12:30 PM, Magentus <magentus gmail com> wrote:

> On Mon, 21 Sep 2009 14:10:34 +0200,
> Nicolas <c r n a wanadoo fr> wrote:
>
> > I made a simple program to fill a liststore with a sqlite db (name,
> > age, sex).  But, i have a problem, someone knows how to save in the
> > db when user change a cell ?
>
> Not an answer to your question...  I was just wondering, is there any
> plan to construct a TreeModel that can represent an SQLite database
> (or a view thereof)?  I'm likely going to have a similar requirement
> soonish, and feel this would be the "right" way to do it.
>
> Rationale: ListStore and TreeStore are simply alternative
> implementations of TreeModel, so it sort of surprises me there isn't
> already an SQLiteStore which I would think, would quite neatly
> side-step a big part of this issue.  Read a row of the store, and a
> the data is fetched from the backing database.  Write new data to the
> store, and that data is written to the backing database.
>
> Additionally: Slip in an "overlay" (similar to the sorting and filtering
> presently supported) to act as a commit buffer, and you'd have a basic
> but quite effective database front-end.
>
> Additionally(2): Combine that with a connector that can connect the
> fields of a TreeModel row with widgets in a UI, and you could very
> quickly build up a pretty substantial database-driven interface.  I have
> something that rather poorly implements such a connector between
> widgets and a struct, but none the less works pretty well (it even
> allows apply/revert by being attached to a memdup()d copy of the real
> struct).  I've been mulling over the idea of building a
> back/front-connector pair; front connectors map a single field of a
> back connector to a widget or whatever else, with helper functions to
> establish the required signals to any suitable widget (widgets could
> even implement a front-connector interface making them instant
> candidates).  The back connector maps its fields to a TreeModel row, or
> a struct, key=value format file, or whatever else.  But quite frankly,
> I'm not that good with GValue, to do the idea justice.  :(
>
> --
> Fredderic
>
> Debian/unstable (LC#384816) on i686 2.6.30-1-686 2009 (up  3:09)
>
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list