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

On 14 December 2011 20:40, Daniel Espinosa <esodan gmail com> wrote:
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.

Ok, that looks good!

>> * 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 the example is very simple and can be kept to a few files then Ok, otherwise I prefer to have several small examples, each to illustrate a specific problem (see my previous mail). If the example is too big, one can get lost and the didactic value is lost.

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

Yes, that's the best!

>> 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 */
return gda_data_data_model_iterable_new (dataselectobject);
return dataselectobject;

I'd prefer that the providers be left unmodified for now, and keep the vala as an extension which adds more features (or presents some features in a different way, as it's what you've done so far). The code just above creates more problems because tests have to be done with and without the vala extension, which is not what I want to do.

> 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.

Ok, good to know!

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.

The GdaDataSelect is at the moment very much part of the provider's code (it exposes many of its internals... I know it' not good, but it's the way it currently is...), and it uses some low level C tricks to work, so please don't try to modify it.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]