I've finished most of the samples and Unit Tests for an implementation of Gee interfaces that allows you to:

* Create a database row, set its values and append to the table in the table. Any column not set in your object is set to its default.
* Create a GObject derived from GdaData.Record to manage information in a database. Object persistence.* Create a object to iterate, chop or filter over all Records in a Gda.DataModel. Called RecordCollection that implements Gee's interfaces Collection, Iterable and Traversable
* I've added a set of interfaces, that use Vala's Generics, in order to allow others to implement the same functionality using other database wrapper different than GDA. GdaData namespace contains all these interfaces definitions and a set of classes implementing them using GDA infrastructure.

=== Comming API changes ====

* Field is defined as a generic class, I want to change it as not generic.* DbCollection, DbSchema, DbTable and its class implementators DataBase, Schema and Table, will be updated as required to implement new functionalities

=== Comming Planned Features ===

==== Milestone 2: DbTable and Table ====* Allow to synchronize fields attributes, foreign keys and list of tables that reference it* Allow to create new tables in databases, by using a HashMap collection holding fields definitions

==== Milestone 3: DbSchema and Schema ====* Allow to get DbTables/Tables from database* Allow to add new schemas to database

Even though I haven't yet had the time to have a deep look at what you have done (and plan to do as explained above), I guess it will be good for Libgda's useability in Vala projets, and I thank you a lot for that. However before moving on to the next milestones could you first take into account these points:

add some documentation about what you have done, in the doc/C/ directory to help people getting started (including me) with Libgda and Vala

as a side note, the .gir files (at least the one in libgda/) are currently managed by git whereas they should normally not because they are generated at compile time. From what I understand, having the gir files managed by git is a current workaround for bugs, but that cannot IMO remain like that in the future (i.e. the gir files must be the ones generated at compile time).