Alex Shinn wrote:
the column info should be present once, not duplicated for every
row. Since you may want to manage a huge number of rows in memory
at once it makes sense to optimize for size. This could be a vector
but it would probably be best to leave it unspecified and use an
opaque accessor to retrieve fields, so that individual backends
could just provide direct access to the row objects returned by the
C library, without needing to copy any data.
+1
Utility functions could convert a row into an alist, in case the
programmer needs/prefers one.
We should certainly build the DBI layer, but we should include
something like SchemeQL on top of it. However, a big complaint I
have with SchemeQL is that it's entirely macro-based, and provides
no way to leverage its power to build dynamic queries. Our SchemeQL
should be combinator based (something like the sql egg)
What's wrong with the sql egg? Can't we just use that, maybe improve
it a bit?
Tobia
_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users
