Re: [Vala] [gnome-db] Branch 5.x series?

[Daniel Espinosa <esodan gmail com>]

2011/12/14 Vivien Malerba <vmalerba gmail com>:
> On 13 December 2011 22:39, Daniel Espinosa <esodan gmail com> wrote:
> > 2011/12/13 Vivien Malerba <vmalerba gmail com>:
> > > On 13 December 2011 18:22, Daniel Espinosa <esodan gmail com> wrote:
> > > > I'm continue in development of Vala extensions on libgda-vala branch,
> > > > I can't tell that is API stable, then I don't merge soon.
> > > >
> > > > But what about to branch 5.0 development and make master point to 6.0
> > > > unstable. May we can make API/ABI changes like the ones on GdaNumeric,
> > > > I would like to do the same for most GDA structs (GdaBlob and others)
> > > > to add API to access its members.
> > >
> > >
> > > I've just created the LIBGDA_5.0 branch for the next 5.0.x releases, and
> > > now
> > > the master branch will be used for the 5.2 release later on, so you'll
> > > have
> > > to merge your branch into master without any perturbation to the 5.0.x
> > > versions.
> >
> > Thanks I'll do it ASAP.
> >
> > > > Even I figure out how to make GdaDataModel a Gee Collection like or
> > > > even add LINQ[1] features to Vala using Gee interfaces and GDA as
> > > > backend.
> > >
> > >
> > > I'm afraid you'll have to illustrate with an example so I can understand
> > > fully what you did.
> >
> > I did:
> >
> > * Added a DataModelIterable, this object can be used in foreach
> > instructions in Vala or using while instrucctions using standard Gee
> > Iterators, to filter GValues or chop a number of GValues. This makes a
> > DataModel a linear collection of GValue where you can traverse through
> > one per one. This is a proof of concept about to use Gee Collection
> > interfaces.
>
>
> The GdaDataModelIter object is an iterator over data models. Did you "wrap"
> it or create a new object?

For now I have created a new GObject with a reference to a
GdaDataModelIter created when my object (Gda.DataModelIterator) from a
GdaDataModel using create_iter(). Then this reference is used
internally to iterate over the DataModel by implemented
Gee.AbstractCollection.abstract class.

> > * Added a DataObject to create persistence database objects, you
> > derive objects form Gda.DataObject to modify values in a row in a
> > table.
>
>
> Could you illustrate its usage with an example?

I'm writing an example in samples/vala. This is to create a micro
Accounting system (I've liked to write it for a long time), a Book,
Account(s) and Transaction(s). This will demostrate the use of
GdaData.Object, to manage persistence objects in a database using a
simple GObjects. Is a work in progress.

If you agree, I can merge inmediatly following "commit often, commit
early", in order to show progress and drawbacks!


> > Work in progress:
> >
> > * Implementing GdaDataModel Interface in the iterable object (just
> > wraps an internal reference to a GdaDataModel)
> >
> > * Implementing Gee.Collection interface to manage DataModel's GValue
> > as a Collection
> >
> > Future Ideas:
> >
> > * How to make use of GDA a Collection provider. Programers will be able
> > to:
> >
> >   - Access GValue stored in a table by using Gee interfaces
> >   - Access Rows in the table and filter them by using fields value
> > expressions. This may requires to modify or add a new interface to Gee
> > like a Collection of Hashes, each hash have field name as key and a
> > GValue as value
> >   - Filter Data from a database using commands like LINQ by compling
> > using Vala. GDA can be called by Vala to pass a string representation
> > of the query to execute a query to the database and return a
> > Gee.Collection. This may require for GDA to parse these kind of SQL
> > commands. A LINQ example code from Wikipedia is:
> >
> > int someValue = 5;
> >
> > var results =  from c in SomeCollection
> >               where c.SomeProperty < someValue * 2
> >               select new {c.SomeProperty, c.OtherProperty};
> >
> > foreach (var result in results)
> > {
> >        Console.WriteLine(result);
> > }
> >
> >
> > * Ideally All providers could return just Iterable and Collection
> > DataModels, but that requires to modify providers implementation. As
> > Vala can create C code to refer to, may be using conditionals  is
> > possible to include libgdadata.h to return iterable objects.
>
>
> All providers return a GdaDataSelect object, which can be used to write data
> back to the database. This object is quite complicated, and I don't plan to
> remove it, but if you need some more features out of it, it can of course be
> modified.

I think that for now GdaDataSelect must stay *as is* for now. I think
to do thinks like:


/* Code in providers to create a GdaDataSelect Object */
#ifdef ENABLE_VALA_EXTENSIONS
return gda_data_data_model_iterable_new (dataselectobject);
#elseif
return dataselectobject;
#endif

> There is one last question I have: are your extensions to be used only by
> programmers using Vala, or (as Vala generates C code) are they also
> available to any language like Libgda currently is (through GObject
> introspection)?

This extensions provides a libgdadata.h file, witch you can use in any
C code - including GDA C files!-. You can create derived GObjects from
the Vala's objects, because all the code is translated to C and C
headers. For other applications don't using Vala can use extensions' C
headers to access the improvements and new features.

GdaDataSelect can be re-written in Vala or create a replacement in
pure Vala and in the future replace it as returned DataModel from
providers. If this too crazy, we can just to add objects in Vala
extensions and allow Providers to use them without modify actual
implementations. I don't want to break API/ABI, just add new features.

If this features are useful, we can enable extensions as default to
depend on Vala compiler.


-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)