Christian Henning wrote:

Hi there,

I like and use SOCI, as well. Although, today I found out about litesql and I like their approach of generating c++ code from xml based table definitions. So, I think a cross of both would be nice.

Interesting, but this seems fairly limited to a very specific mapping. What if I need to change the mapping names or key associations? And, I have come out of the closet -- I hate xml as a primary 'input language'. If you're going to all the trouble of writing a generator, why not write one with simplified data specification language? Off the top of my head -- imagine something like more like this: schema example { type Mother; //forward declare type Father; type Office; type Role {}; type Employee : Role { //1 to many bi-directional, required Office office <-> employees[0..*]; } type Office { Employee employees[0..*] <-> office; //needs to match Employee } type Student : Role { } type School { string name; } //alternative way to specify a relation outside the type //Student will have an optional relation to school //School will have 0 to many students relation StudentSchool { Student.school[0..1] <-> School.students[0..*]; } enum Sex { Male=0, Female=1 }; //The obvious mapping Table = Person type Person { string name; //mapped to column name in table Person Sex sex; integer age = 0; //automatically generates Table PersonRoles Role roles[0..*]; //unidirectional 0..m relation //Generates a field for mother id Person mother; //unidirectional required relation Person father; //automatically generates a join table PersonSiblings Person siblings[0..*] <-> siblings[0..*];//bidirectional m-m }; } database Exampledb uses schema example;

I did my own code generator on top of SOCI but not with all the bang that litesql have. The good thing about generators is that you would deal with sql statements a lot less, since they can be generated by the code generator. The C++ on SOCI generator might be a nice project for SoC.

Possibly, but to accept such a project we would be over the edge of *not boost* since SOCI isn't part of Boost. Yes, the intention is there, but there's literally hundreds of other proposals where the intention was there. Getting SOCI Boostified has a direct relation to Boost. All that said, we did accept a couple projects last year that were more related to 'C++' in general than Boost, so it might be possible we would be willing to do one of these.

This reminds me: I always wanted to ask if there is something similar to Javaspaces ( http://en.wikipedia.org/wiki/JavaSpace ) out there for C++.

The OMG has a specification call Data Local Reconstruction Layer which provides this sort of functionality in a cross-language/platform manner. Unfortunately, there's no open source implementation of it and it's incredibly complex to create one. It's a good idea though... http://www.omg.org/cgi-bin/doc?formal/07-01-01 Jeff

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