Jeff Garland wrote:
Dmitri Lyfar wrote:
Hi I would like to participate in Google Summer of Code in this year.
Great, welcome! Note, this discussion would probably be better hosted in the development list, so I've cross-posted it there.
I reviewed boost projects for last years and found an interesting project, I think. If you go to the link below you will see a short description for that library: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer...
The goal of this post is to define the main library features, which will be useful for users. Is that library useful for C++ community? If you are using(or have ever used) similar C++ libraries for work with SQL: which of features do you want to have? Also I want to notice one of the biggest beauty of that approach: you can get the compiler to type-check the SQL-expression, what do you think about that?
Well, I'll be brutally honest -- I don't think I would go that direction. We didn't pick a database project last year because a majority of the mentors agreed that the 'dsl-based' approach was more of a toy than reality. The main reason for this is that in 'real-world' applications queries are often dynamic and must be built at run-time. So, before we get ahead of ourselves and think about 'sql embedded in C++' we need the basics of getting database access.
Our FOST.3 framework handles SQL generation within C++. There are two separate aspects to a library like this. One is the generation of the CRUD SQL and the other is generalised queries. We took the view that the CRUD operations are important within the C++ so that we can use the SQL database as an object store. The generalised queries are less important (in our opinion) as they are most easily crafted in SQL and for security reasons it is best to have them as stored procedures wherever possible. As for the schema mappings we start with UML and compile that into the relevant C++ code and a database. The C++ code includes some static binding information and the database also includes some dynamic binding information. This gives a fair bit of flexibility in that the C++ class used to represent a given object in the database is determined by the dynamic bindings (which carries no speed penalty as the mapping must be done anyway) but once the C++ implementation has been chosen then the static bindings take over. We don't have any public information about the low-level aspects of the libraries, but there is some on the higher level aspects supported along with some example schemas. We're moving the web server everything sits on today, but if anybody's interested I can post a few links after it's been done. Kirit