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



2011/12/15 Vivien Malerba <vmalerba gmail com>:
>
>
> 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.
>

I've finished two examples:

* samples/vala/SampleDataObject: This shows how to create a
GdaData.Object derived class and how to use its methods for get,
update and save values. The next step will be a why to add new objects
to the database.

* samples/vala/SampleDataModelIterable: This shows how to use Gee
Collection capabilities to iterate, chop, filter and stream all GValue
in a datamodel. The next step is to create a Per-Row iteration.

I'll send two different e-mail to talk about new some problems and
features I've want to see on vala extensions:

a) A problem with GdaDataModel interface implementation and how to
implement it on Vala code

b) A new paradigm for GDA: DataBase as Gee Collection of Collections

>>
>>
>> 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 */
>> #ifdef ENABLE_VALA_EXTENSIONS
>> return gda_data_data_model_iterable_new (dataselectobject);
>> #elseif
>> return dataselectobject;
>> #endif
>
>
> 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.
>

Ok I'll keep away vala extensions off the core for now.

>>
>>
>> > 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.
>
> Thanks,
>
> Vivien



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


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