Re: [boost] SOCI 2.2.0 - The C++ Database Access Library
From: Beman Dawes <bdawes@acm.org>
Austin Bingham wrote:
Or how about Boost.Database, following the lead of Boost.Filesystem? They both do the same kind of thing.
Boost.Database seems exactly right to me.
It's an improvement on SOCI or DAL, but it doesn't quite work for me. I can imagine thinking that this might be a database library more like Sleepycat or cdb rather than an interface to backend databases. What about BDBC - Boost Database Connectivity? (Which intentionally mirrors ODBC...) The mascot can be Twiki from Buck Rogers. :) BDBDBDBDBDB...C - James Jones Administrative Data Mgmt. Webmaster 375 Raritan Center Pkwy, Suite A Data Architect Edison, NJ 08837
james.jones@firstinvestors.com wrote:
From: Beman Dawes <bdawes@acm.org>
Austin Bingham wrote:
Or how about Boost.Database, following the lead of Boost.Filesystem? They both do the same kind of thing. Boost.Database seems exactly right to me.
Unfortunately there's already an abandoned Boost.Database in the sandbox -- so that might be confusing.
It's an improvement on SOCI or DAL, but it doesn't quite work for me. I can imagine thinking that this might be a database library more like Sleepycat or cdb rather than an interface to backend databases.
How about database access abbreviated to dba -- hmm that kinda has a nice ring :-)
What about BDBC - Boost Database Connectivity? (Which intentionally mirrors ODBC...) The mascot can be Twiki from Buck Rogers. :) BDBDBDBDBDB...C
I'm sorry to say that I got this joke. But really BDBC is an awful mouthful. ..dbc might be ok. Jeff
Boost.Database seems exactly right to me.
Unfortunately there's already an abandoned Boost.Database in the sandbox -- so that might be confusing.
They appear, however, to do exactly the same thing. That is, if one is accepted, the other will be rightly dumped. Since one is abandoned and the other very much alive, I think the concern over potential confusion is minimal.
It's an improvement on SOCI or DAL, but it doesn't quite work for me. I can imagine thinking that this might be a database library more like Sleepycat or cdb rather than an interface to backend databases.
How about database access abbreviated to dba -- hmm that kinda has a nice ring :-)
What about BDBC - Boost Database Connectivity? (Which intentionally mirrors ODBC...) The mascot can be Twiki from Buck Rogers. :) BDBDBDBDBDB...C
I'm sorry to say that I got this joke. But really BDBC is an awful mouthful. ..dbc might be ok.
Whatever we pick, I think we should avoid any name that isn't pretty immediately clear on a quick scan. With a few exceptions (i.e. Spirit), you can quickly tell what a boost library does based solely on it's name. So, while "database" gives a pretty good clue as to the library's purpose, "bdbc" or "dba" are less informative. As the list of boost libraries grows, I think it behooves us to avoid obfuscation and, thus, confusion. -- Austin Bingham Signal & Information Sciences Laboratory Applied Research Laboratories, University of Texas at Austin 10000 Burnet Rd., Austin, TX 78758
Austin Bingham wrote:
Boost.Database seems exactly right to me. ow about database access abbreviated to dba -- hmm that kinda has a nice ring :-)
What about BDBC - Boost Database Connectivity? (Which intentionally mirrors ODBC...) The mascot can be Twiki from Buck Rogers. :) BDBDBDBDBDB...C I'm sorry to say that I got this joke. But really BDBC is an awful mouthful. ..dbc might be ok.
Whatever we pick, I think we should avoid any name that isn't pretty immediately clear on a quick scan. With a few exceptions (i.e. Spirit), you can quickly tell what a boost library does based solely on it's name.
Right, I think Boost.DatabaseAccess is pretty clear.
So, while "database" gives a pretty good clue as to the library's purpose, "bdbc" or "dba" are less informative. As the list of boost libraries grows, I think it behooves us to avoid obfuscation and, thus, confusion.
Let me be clear that there's 2 names I'm talking about. One is the 'library' and one is the namespace. database:: or database_access:: is too long for normal use. Just as filesystem:: is typically more verbose than we want. So while filesystem is indeed in namespace filesystem this is commonly aliased to fs:: in code...I think even in the docs as I recall. So it would be nice if there is a good abbreviation for namespace aliases that is short and clear. db or dba both work for me. Oh and I'm still worried about the confusion with just plain Boost.database because archives and sandbox stuff tends to hang around forever. And although they are in the same domain they are nothing like each other. So I haven't heard any opinion from the authors and they are the folks that matter most... Jeff
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Garland Sent: 07 December 2006 22:37 To: boost@lists.boost.org Subject: Re: [boost] SOCI 2.2.0 - The C++ Database Access Library
Whatever we pick, I think we should avoid any name that isn't pretty immediately clear on a quick scan. With a few exceptions
(i.e. Spirit),
you can quickly tell what a boost library does based solely on it's name.
Right, I think Boost.DatabaseAccess is pretty clear.
But rather long :-( How about Boost.DataAccess and boost::dataaccess? Or even my original suggestion Boost.Access and boost::access? I suggested it somewhat mischeviously, but the more I think about it, the more I like it. One might even access Microsoft Access (TM) with it? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
Whatever we pick, I think we should avoid any name that isn't pretty immediately clear on a quick scan. With a few exceptions (i.e. Spirit), you can quickly tell what a boost library does based solely on it's name.
Right, I think Boost.DatabaseAccess is pretty clear.
But rather long :-(
Not when abbreviated to dba.
How about Boost.DataAccess and boost::dataaccess?
No, I think the 'base' is important here. DataAccess might include xml files, but the library doesn't do that.
Or even my original suggestion Boost.Access and boost::access?
I suggested it somewhat mischeviously, but the more I think about it, the more I like it. One might even access Microsoft Access (TM) with it?
Even less context then DataAccess. Access leaves me thinking, Access to what? I thing database needs to be spelled out somewhere in the name otherwise we've lost something. If I were getting picky I'd want to see the word 'Relational' in there b/c the library can't access object databases. Jeff
Jeff Garland wrote:
Paul A Bristow wrote:
Right, I think Boost.DatabaseAccess is pretty clear.
But rather long :-(
Not when abbreviated to dba.
dba is often used as an abbreviation of database administrator, so I believe it may confuse.
Or even my original suggestion Boost.Access and boost::access?
I suggested it somewhat mischeviously, but the more I think about it, the more I like it. One might even access Microsoft Access (TM) with it?
Even less context then DataAccess. Access leaves me thinking, Access to what? I thing database needs to be spelled out somewhere in the name otherwise we've lost something. If I were getting picky I'd want to see the word 'Relational' in there b/c the library can't access object databases.
Jeff
I haven't studied the documentation in detail but from the SOCI Rationale FAQ (http://soci.sourceforge.net/doc/rationale.html) "The basic SOCI syntax was inspired by the Embedded SQL, which is part of the SQL standard, supported by the major DB technologies and even available as built-in part of the languages used in some DB-oriented integrated development environments." I'd agree with Paul Bristow about using boost.sql. For me SQL implies a method of accessing a relational database and is also an obvious and well know concept. boost.database initially sounds nice if you only work with relational databases, but once you consider the mryaid of other types of databases (object based, hierarchical, temporal,.dimensional...) I feel it's not specific enough. Regards Mark
Mark Blewett wrote:
dba is often used as an abbreviation of database administrator, so I believe it may confuse.
I realize....that's why I like it...
I haven't studied the documentation in detail but from the SOCI Rationale FAQ (http://soci.sourceforge.net/doc/rationale.html)
"The basic SOCI syntax was inspired by the Embedded SQL, which is part of the SQL standard, supported by the major DB technologies and even available as built-in part of the languages used in some DB-oriented integrated development environments."
I'd agree with Paul Bristow about using boost.sql.
For me SQL implies a method of accessing a relational database and is also an obvious and well know concept.
Well, actually this isn't a good name because SOCI isn't really an SQL handling library. In fact it explicitly avoids sql and focuses more on database access.
boost.database initially sounds nice if you only work with relational databases, but once you consider the mryaid of other types of databases (object based, hierarchical, temporal,.dimensional...) I feel it's not specific enough.
The reason I'm ok with dropping the 'Relational' is that relational db's the 80% case (or more, sadly) and folks looking for the other databases are specialists that will figure out in 2 seconds of document study that boost.dbaccess isn't for them. Jeff
Jeff Garland wrote:
Mark Blewett wrote:
I haven't studied the documentation in detail but from the SOCI Rationale FAQ (http://soci.sourceforge.net/doc/rationale.html)
"The basic SOCI syntax was inspired by the Embedded SQL, which is part of the SQL standard, supported by the major DB technologies and even available as built-in part of the languages used in some DB-oriented integrated development environments."
I'd agree with Paul Bristow about using boost.sql.
I like it too. It also indicates that the (SOCI) library provides data access based on SQL. In fact, it is strongly based on SQL, so it also determines what data sources can be supported - SQL-based.
For me SQL implies a method of accessing a relational database and is also an obvious and well know concept.
Well, actually this isn't a good name because SOCI isn't really an SQL handling library. In fact it explicitly avoids sql and focuses more on database access.
Yes, but I can't think (now) about using SOCI with data source which doesn't support SQL as mechanism for operating data. Cheers -- Mateusz Loskot http://mateusz.loskot.net
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. 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. 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. Anybody willing to submit a backend for this? ;-) (Warning: table joins are more tricky.) 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. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/
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
My two pennies; ** The name: I'd love to see boost::data_access / Boost.DataAccess. I would probably alias it to da. Rationale: SOCI seems to be entirely about accessing data. The Data can be arbitrary. It just makes sense to keep it as a generic term like DataAccess. DatabaseAccess implies that it works only against a physical database. Drawbacks: I can think of none. ** The connection string: My vote is to use a standard URI mechanism, like odbc://username:password@server/dsn or mysql://username:password@hostname/test, etc. Rationale: It's a standard well understood mechanism. Drawbacks: May be too limiting. You can generally append whatever named parameters you want as part of the query string: odbc://me:secret@localhost/gumball_shop?auto_commit=false&connection_pooling=true Things can get ugly pretty fast. That said I don't see why some sort of specialized builder for any backend couldn't be used to create the connection string. -- Scott Deming http://www.makefile.com
David Abrahams wrote:
Maciej Sobczak <prog@msobczak.com> writes:
SOCI focuses on *relational data*
Boost.Relational seems like an obvious choice.
Two objections: its Hamming distance from Boost.Rational is too short and might be confused with the Relational Template Library. Cheers, Nicola Musatti
Jeff Garland wrote:
Mark Blewett wrote:
dba is often used as an abbreviation of database administrator, so I believe it may confuse.
I realize....that's why I like it...
I haven't studied the documentation in detail but from the SOCI Rationale FAQ (http://soci.sourceforge.net/doc/rationale.html)
"The basic SOCI syntax was inspired by the Embedded SQL, which is part of the SQL standard, supported by the major DB technologies and even available as built-in part of the languages used in some DB-oriented integrated development environments."
I'd agree with Paul Bristow about using boost.sql.
For me SQL implies a method of accessing a relational database and is also an obvious and well know concept.
Well, actually this isn't a good name because SOCI isn't really an SQL handling library. In fact it explicitly avoids sql and focuses more on database access.
After reading Maciej Sobczak's very informative post I agree. Whilst surfing wikipedia, for inspiration I stumbled across the entry for ODBC; "In computing <http://en.wikipedia.org/wiki/Computing>, Open Database Connectivity (ODBC) provides a standard software <http://en.wikipedia.org/wiki/Software> API <http://en.wikipedia.org/wiki/Application_programming_interface> method for using database management systems <http://en.wikipedia.org/wiki/Database_management_system> (DBMS). The designers of ODBC aimed to make it independent of programming languages <http://en.wikipedia.org/wiki/Programming_language>, database systems, and operating systems <http://en.wikipedia.org/wiki/Operating_system>." Boost Database Connectivity or boost.dbc?
boost.database initially sounds nice if you only work with relational databases, but once you consider the mryaid of other types of databases (object based, hierarchical, temporal,.dimensional...) I feel it's not specific enough.
The reason I'm ok with dropping the 'Relational' is that relational db's the 80% case (or more, sadly) and folks looking for the other databases are specialists that will figure out in 2 seconds of document study that boost.dbaccess isn't for them.
I agree, but if there's a name out there which conveys what the libray is about in a short and precise way it would surely help. However I know choosing a name is one of the most difficult and controversial things in software engineering! Regards Mark
Paul A Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Garland Sent: 07 December 2006 22:37 To: boost@lists.boost.org Subject: Re: [boost] SOCI 2.2.0 - The C++ Database Access Library
Whatever we pick, I think we should avoid any name that isn't pretty immediately clear on a quick scan. With a few exceptions (i.e. Spirit), you can quickly tell what a boost library does based solely on it's name.
Right, I think Boost.DatabaseAccess is pretty clear.
But rather long :-(
How about Boost.DataAccess and boost::dataaccess?
Or even my original suggestion Boost.Access and boost::access?
What about this one: Boost.DataAccess, this name could be long, as Unit Test Framework is long too. But namespace could be boost::db_access, not longer than boost::unit_test.
One might even access Microsoft Access (TM) with it?
Sure. There is ODBC backend test for MS Access in the SOCI CVS. Cheers -- Mateusz Loskot http://mateusz.loskot.net
How about boost:dbi? short for database interface. Its short, obvious and to the point. ----- Original Message ----- From: "Mateusz Loskot" <mateusz@loskot.net> To: <boost@lists.boost.org> Sent: Friday, December 08, 2006 11:19 AM Subject: Re: [boost] SOCI 2.2.0 - The C++ Database Access Library
Paul A Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Garland Sent: 07 December 2006 22:37 To: boost@lists.boost.org Subject: Re: [boost] SOCI 2.2.0 - The C++ Database Access Library
Whatever we pick, I think we should avoid any name that isn't pretty immediately clear on a quick scan. With a few exceptions (i.e. Spirit), you can quickly tell what a boost library does based solely on it's name.
Right, I think Boost.DatabaseAccess is pretty clear.
But rather long :-(
How about Boost.DataAccess and boost::dataaccess?
Or even my original suggestion Boost.Access and boost::access?
What about this one:
Boost.DataAccess, this name could be long, as Unit Test Framework is long too. But namespace could be boost::db_access, not longer than boost::unit_test.
One might even access Microsoft Access (TM) with it?
Sure. There is ODBC backend test for MS Access in the SOCI CVS.
Cheers -- Mateusz Loskot http://mateusz.loskot.net _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Send instant messages to your online friends http://au.messenger.yahoo.com
participants (11)
-
Austin Bingham -
David Abrahams -
james.jonesīŧ firstinvestors.com -
Jeff Garland -
Maciej Sobczak -
Mark Blewett -
Mateusz Loskot -
Minh Phanivong -
Nicola Musatti -
Paul A Bristow -
Scott Deming