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?
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.
Right, interesting.
Consider:
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. Cheers -- Mateusz Loskot http://mateusz.loskot.net