From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2006-12-08 07:58:28
Maciej Sobczak wrote:
> Mateusz Loskot wrote:
>> Yes, but I can't think (now) about using SOCI with data source which
>> doesn't support SQL as mechanism for operating data.
> No problem with this.
Heh, I knew there is a surprise hiding somewhere ;-)
> SOCI does not impose any interpretation on the
> query string, it might be whatever the backend/server understands. After
> all, a single stored procedure call isn't that much SQL specific, right?
> It's just the matter of statistics that all existing SOCI backends deal
> with SQL servers, but that is not a principle. If anybody jumps in with
> the backend for CSV files that use grep/sed parameters' syntax as the
> basis for the query language (for example), it will work just fine.
> session s("csv:///etc/protocols");
> rowset<string> rs = (s.prepare << "1:*");
> copy(rs.begin(), rs.end(), ...);
> where "1:*" is taken from the top of my head and would mean "first field
> from all rows".
> That would be the SOCI way to get the list of network protocols on your
> Linux machine.
Sounds cool, I've not guessed this use case at first.
I'd love to see this feature in SOCI ;-)
> SOCI focuses on *relational data* - the query language doesn't really
> matter. That's why I'm a bit reluctant to use SQL in its name.
Another use case I think about after seeing example above would
be XQuery/Xpath support for querying XML trees.
All this looks very promising, indeed.
-- Mateusz Loskot http://mateusz.loskot.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk