OK, thanks ! Do you by any chance know what would be the best equivalent of a persistent hash table (on disk) , with emphasis on processing speed (and without SQL or any suchlike overhead) in Vala.
In C,it would be gdbm or Berkeley DB or Tokyo Cabinet, for instance. Serge. On Sat, Dec 24, 2011 at 5:12 AM, Daniel Espinosa <[email protected]> wrote: > No really. > > I'll use real database engines through GDA. > > I'm seeing Gee just for its interfaces. I plan to implement them with > minimal info in memory, just results of queries. > > GDA have an experimental implementation of Gee Collection for GdaDataModel > and some interfaces to model a database in Gee Collections, but using > GdaMetaData to retrieve info from any Gda supported database. > > Also hope to model queries in a way that in feature Vala could gain LinQ > like suport. > El dic 23, 2011 3:31 a.m., "Serge Hulne" <[email protected]> escribió: > >> I assume that you are considering developing a database system in RAM >> (since you mentioned Gee). >> >> Also I am assuming that you are considering a relational model (with >> tables >> and relationship between tables, etc..., possibly with SQL). >> >> 1. Here is an example of an implementation in Java. >> http://hsqldb.org/ >> >> 2. Here is an example of an implementation in Python. >> http://gadfly.sourceforge.net/ >> >> 3. Alternatively NoSQL databases (also worth considering): >> http://en.wikipedia.org/wiki/NoSQL >> >> 4. Since Gee already has Maps, which are not unlike "tables in RAM" (whose >> keys are accessed via a hash function) and since Vala has got generics (in >> the shape of templates), it is very easy to create a non persistent >> database in RAM as: >> >> - a HashMap >> - a MultiMap >> - a "map" of "maps" (a map having maps as keys, again: generics make this >> very easy) with the help of which complex relationships can be expressed >> between "tables" in RAM, without the overhead and runtime penalty of SQL. >> >> So the question of whether it is worth developing an additional layer of >> abstraction on top of Gee is actually a good question. >> Food for thoughts ! >> >> Perhaps the most important question to consider would be: >> >> - What would be the aim of this construct on top of Gee: >> >> 1. expressing relationships between tables (implementing a relational >> model) ? >> 2. Building an in-RAM easy-to-use DBMS. >> 3. With of without SQL ? >> 4. Store Classes (objects) : Like ORM models : Object-to-relational >> databases. >> 5. is ease-of-use the foremost priority ? >> 6. is speed the top priority ? >> 7. Is minimal (optimal) use of RAM one of the priorities ? >> >> More concretely : What use do you have in mind for it, in practice ? >> >> Serge. >> >> _______________________________________________ >> vala-list mailing list >> [email protected] >> http://mail.gnome.org/mailman/listinfo/vala-list >> >>
_______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
