The POCO C++ Libraries Blog

Introducing POCO Data

Filed under: News by guenter at 17:42

The Data library is POCOs new database abstraction layer. It features a generic SQL data access framework which defines interfaces for DataConnectors. A DataConnector implements the plumbing between Data and an actual database API (e.g., ODBC, OCI, etc.)

POCO Data heavily builds on ideas borrowed from SOCI, another excellent database abstraction library under the Boost license.

The source code for POCO Data currently lives in the SVN Sandbox. The only DataConnector currently available is for SQLite, which limits the usability of POCO Data somewhat ;-). However, more connectors (ODBC, OCI) will be available soon.

An overview and user manual for POCO Data can be found here.

If anyone wants to contribute connectors (e.g. to MySQL, SQL Server, PostgreSQL, DB2), you are welcome!

  1. This implementation seems to me to be a port of SOCI to Poco. If the intent is to mimic SOCI why not simply contribute to the SOCI project. I am sure they could use your help. The thing is C++ desperately needs a standard RDBMS access library. It appears SOCI aims to achieve this. But am not sure they have what it takes to implement a trully industrial strength library.
    Right now I am using OTL together with Poco because I don’t think SOCI is there yet. OTL is more complete and mature but SOCI seems better architected so it is likely to succeed. I was looking foward to the promised Poco data but if the goal is to re-do SOCI I might as weel wait for SOCI to mature.
    May be I am pre-judging here Poco::data but am kind of library junky so I will give a it fare try..


    Comment by Vlad on September 22, 2006, 06:02

  2. Well,
    I have to object.
    PocoData is NOT a port of SOCI. We took the SOCI library as inspiration source, and redesigned and implemented it from scratch. SOCI has a very good interface, so there was no need to reinvent it. We simply changed the parts where we felt it improves the usage of PocoData.
    About contributing to SOCI: too much work. With our interface changes most parts of SOCI would have been in need of a rewrite, probably the same is true for their connector implementations. Add to that the time effort to understand
    their code, to communicate changes…
    Way faster to start from scratch 🙂

    Comment by pschojer on September 22, 2006, 09:14

  3. One way or the other, there are two parallel very similar implementations. It is sad that this is the case because way more could be achieved if the two teams joined the eforts. I have invited SOCI folks to join the Poco community and effort but they declined it. So, for the time being, the efforts shall continue in parallel.


    Comment by alex on September 25, 2006, 12:48

  4. How about designing PocoData simply as warapper around SOCI. This would enhance the usability of Poco if SOCI ever gets accepted into Boost.


    Comment by Cornell on September 25, 2006, 14:44

  5. I’m not sure I understand how SOCI boostification would enhance usability of Poco. And wrapping a wrapper which wrapps other wrappers sounds like a bit too much wrapping.


    Comment by alex on September 25, 2006, 18:29

  6. Enhance adoption would have been a better term. Boost libraries have a growing mindshare, although I myself am not a fan of their extreme emphasis on templates. Boost based code takes forever to compile..
    However, if Poco can integrate nicely with Boost it sure would help speed up adoption among Boost fans.
    A wrapper on top of wrappers sounds convuluted I agree but you take advantage of the work done by potentially hundreds of other developers while concentrating on other parts of Poco.


    Comment by Cornell on September 25, 2006, 21:57

  7. I don’t see how wrapping SOCI would enhance adoption of Poco either. Poco can already integrate nicely with Boost. For example, Peter’s reply to my query about tuples explains how:
    Well, Poco::Tuple is currently not planned, but it should be possible to use boost::tuple in PocoData by providing the necessary TypeHandler template specializations.
    [end quote]
    However, I’d have to have a good reason to couple myself with another library. Generally speaking, tight coupling (and dependencies in general) are bad. Same is probably SOCI’s developer’s concern when considering a ‘merger’ with anyone. At any rate, I think we are beating a dead horse here.


    Comment by alex on September 26, 2006, 12:11

RSS RSS feed for comments on this post. TrackBack URI

Leave a comment