Re: [Vala] [gnome-db] Branch 5.x series?
Daniel Espinosa <[email protected]> Thu, 22 Dec 2011 14:27:48 -0600
| Newsgroups | gmane.comp.programming.vala,gmane.comp.gnome.db,gmane.comp.lib.gee |
|---|---|
| Message-ID | <CAHirWtK5aFACAtqL0Mzm0x3HUUqJUvZptA7B1bVFcexrX2Pvdg@mail.gmail.com> |
2011/12/15 Vivien Malerba <[email protected]>: > > > On 14 December 2011 20:40, Daniel Espinosa <[email protected]> wrote: >> >> 2011/12/14 Vivien Malerba <[email protected]>: >> > >> > >> > On 13 December 2011 22:39, Daniel Espinosa <[email protected]> wrote: >> >> >> >> 2011/12/13 Vivien Malerba <[email protected]>: >> >> > >> >> > >> >> > On 13 December 2011 18:22, Daniel Espinosa <[email protected]> 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) _______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list