[rdb] 0.0.10 + documentation
I have uploaded a new revision to the vault. The only /visible/ change in the API is the syntax for the insert...select statement. It was `insert_into(table)(cols)(select(...))`, it is now `insert_into(table)(cols).select(...). The syntax engine is beginning to look more and more like a compile-time finite state machine. And there is the beginning of a documentation ! you can view it here : http://www.yorel.be/boost/libs/rdb/doc/html/index.html The tutorial is 2/3 complete for this phase (i.e. sans prepared statements). The structure of the doc is strongly influenced by Fusion's - no wonder, I spent so much time in it ;-) While I like the overall structure, I wonder if the Fusion style is appropriate for a tool that is not so much into meta-programming (well at least on the outside). I documented insert_into in this fashion (see http://www.yorel.be/boost/libs/rdb/doc/html/rdb/sql_subsystem/statements/ins...) for a test. If you have opinions, please voice them. J-L
Hi J-L, Quite a while ago I started to write yet another SQL library. The project can be found at https://sourceforge.net/projects/async-db/ My library has very little in common with your library. While your library is mainly fucused on creating valid SQL strings (please correct me if I am wrong), my library is targeted against prepared statements as function objects and asynchronous operations. Creation of SQL strings is out of scope. All it does (or rather "will do") is wrap the C-APIs of Firebird, MySQL, ODBC, Oracle Call Interface, PostgreSQL and SQLite3. I do not really think that my library is ready to present to the public, but it might be interesting to combine our libraries or use them together as a base for a higher level library. Currently my MySQL backend is the most feature rich one. It supports asynchonous operations, statements as function objects, boost::optional<T> for fields that may be NULL, gregorian::date for field DATE, posix_time::time_duration for TIME and posix_time::ptime for DATETIME. Please have a look at the example at https://async-db.svn.sourceforge.net/svnroot/async-db/trunk/examples/mysql.c... cheers, Daniel
My library has very little in common with your library. While your library is mainly fucused on creating valid SQL strings (please correct me if I am wrong),
...and make sure that the results of the query land in C++ variables in a type-safe manner. Which was the original goal, the idea of preventing the composition of an illegal sql statement came afterward.
it might be interesting to combine our libraries or use them together as a base for a higher level library.
Please have a look at the example at https://async-db.svn.sourceforge.net/svnroot/async-db/trunk/examples/mysql.c...
Yes it looks like it makes sense. My "sql constructors" return models of very simple concepts that contain a few typedefs (a tag, a result type) and a str(ostream&) function for converting the object graph into text. Later I'll have prepared statements too but it seems that it's feasible, maybe even easy, to slip my objects under your framework. Interesting times :-) J-L
participants (2)
-
Daniel Pfeifer -
Jean-Louis Leroy