On 12 April 2013 18:44, Bruce Adams <[email protected]> wrote: > > DTL auto-prepares statements (would you ever not want to do this?)
If I need it, I may consider myself to implement it. If someone needs it, implements it, then (s)he should feel free to submit it to SOCI. > You don't need to say select or insert its implicit in whether you are > reading or writing. > So you just specify one or more tables (joins just work!) That is significant conceptual difference between SOCI and DTL. In SOCI, that's also AFAIU the historical legacy, query in textual form plays important role as a glue that frees us from implementing SQL variants within the library. > There's also a bulk fetch helper which can be used more efficiently than > iteration. > Its not clear to me when SOCI uses bulk fetch. If you use a vector of rows I > think it will just iterate? for all std::vector<T> where T is C++ intrinsic type which SOCI declares to support (see docs). Actual realisation of bulk statements is DBMS-specific. > Finally there is fine control over the mapping of datatypes (for reasons I > forget called a BCA in DTL, and which in C++11 could be a lambda instead). AFAIK, DTL is highly ORM-oriented, whereas SOCI offers ORM as "one of" feature. > I think this is a little less awkward than specialising the type_conversion > template in SOCI > (though I am prepared to be shown wrong by any SOCI gurus) It should be possible to provide automatic type registration to adapt user-defined types automagically. For example, in Boost.Geometry lib I use this technique: http://www.boost.org/doc/libs/1_51_0/boost/geometry/geometries/register/point.hpp Besides, we have Boost.Fusion support that should do the job quite well. > E.g. > > MyRowType rowbuf, > DBView<MyRowType> view("table1, table1", > BCA(rowbuf, > COLS["column1"] >>> rowbuf.column1 && > COLS["column2"] >>> rowbuf.column2), > "where clause here if you > want it"); > bulk_fetch_helper(view.begin(), 500, > std::ostream_iterator<MyRowType>(std::cout, "\n")); Paraphrasing a British diplomatic answer: "it looks, hmm, interesting" :) > So I think there is some room for improvement in SOCI on the ORM side. Sure, there is, but I'd rather wait for C++11 adoption and follow Roland Bock's idea as presented here: http://article.gmane.org/gmane.comp.lib.boost.devel/238774 Note, this kind of ideas have been discussed within Boost community a few years ago already: http://lists.boost.org/Archives/boost/2010/09/170983.php I have an impression that lots of ideas have been held back and postponed until C++11 is published as it opens whole new capabilities in C++ and we shall expect spring of new C++11-only libraries in near future (i.e. Boost.Spirit 3). > I suspect a lot of the success of SOCI, in terms of attracting users, is > based on its ability to make queries look > like embedded SQL (but of course so much better). > I think the success of ORMs and DTL in particular is in hiding the database > wherever possible. > So from the ORM perspective embedding SQL seems like a horseless carriage > (see for example http://www.horton.com/beyondhcthandouts.htm) Yes, it fits very well into the paradigm of OOP in terms of which we all like to think and allows users to actually forget they speak to a database. IMO, ORM is a higher level problem and even the fanciest ORM DSL won't help much if the things are screwed at lower level (like basic types conversions, incomplete implementation of backends, semantic/behaviour incompatibilities between backends, etc.) > The DTL documentation makes no bones about pushing for a modern design away > from the horseless carriage of embedded SQL. > SOCI on the other hand just leaves it to the user. Users coming from the a > background of using SQL directly on the database > will naturally be drawn to the embedded SQL way of thinking and hence prefer > that side of SOCI to its ORM offering. > Java programmers will be drawn the other way from using Hibernate/JPA. We can't fulfil everyone's expectations, I'm afraid. > My agenda here is simply that SOCI+DTL (or even +=) would form a good > starting point for a standard C++ database interface. Generally, yes. In practice, there won't be anything like "great, let's merge our projects". I'm 99% sure if std::database happens, it will be designed and written from scratch completely without looking back. There won't be any code reuse or copying, merging, facading, adapting, and so on. Bootstrapping will happen. Best regards -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
