GNOME.org
 

Re: [Vala] [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]