On 11/09/2013 11:03 PM, Roland Bock wrote:
recently put it on github, and I would really like to hear from you guys whether this is something that could be interesting for you personally or for boost?
I think it could be a very useful addition. Thanks :-)
There are two potential extensions that may be worth considering. I do not consider these extensions required for adoption in Boost, but it may be a good idea to at least have given them some thought.
First, make sqlpp11 work on arbitrary data structures. For instance, SQL is just one data provider in LINQ. I haven't given this much thought yet, but I believe that this should be
On 2013-11-11 16:30, Bjorn Reese wrote: possible by using a different connector. sqlpp11 itself has no idea about evaluating the query. In particular, it does not know anything about database connections. It constructs a query for you which you then can run. And if your result has the correct type, you can interpret it using sqlpp11's result object. Whether the evaluation happens with a database, or by analyzing some XML or JSON, is totally up to the connector. Of course, as mentioned elsewhere, it might be useful to create a query representation which is not a string in those cases :-)
Second, consider adding streaming SQL. Rx is an example of this. This could be done with a Boost.Asio integration.
I just heard about Rx for the first time the other day, so let me see if I get the idea right: Instead of querying a database or a given XML file, you evaluate the query against a stream of incoming data. If a row matches, you call a callback with the selected data? If that's the general idea, I think that can be done as well: A library for evaluating incoming data would get some representation of the template expression and maybe the result_row type. In my opinion, both extensions could be done in additional libraries that make use of the query expressions generated by sqlpp11. A few additions to the interface should be sufficient.
* define types representing tables and columns,
There seems to be room for improvement here. You should consider an integration with Boost.Fusion. This way you can avoid having to build a code generator.
There seems to be a great deal of demand for using Boost.Fusion for the Table/Column types. It would be great if someone could lend me a hand with this. I am going to update the information in the wiki on what kind information sqlpp11 requires asap (hopefully this weekend). PS: In the mail you forwarded me this morning you also asked if I were aware of N3612? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3612.pdf Yes, and I agree with most of the described requirements and wanted to throw my hat in the ring. Personally, I believe that the EDSL-approach is the way to pursue. Falling back to string based is always possible, a library like sqlpp11 does not prevent that.