RE: [boost] Re: Library Proposal: database (boost::db)
Sent: Sunday, October 17, 2004 8:17 AM To: boost@lists.boost.org Subject: Re: [boost] Re: Library Proposal: database (boost::db)
On Sat, 16 Oct 2004 23:35:37 +0000 (UTC), Steve Hutton wrote
On 2004-10-15, Maciej Sobczak <prog@msobczak.com> wrote:
http://www.msobczak.com/prog/soci/
This library aims at simple usage patterns, where intuitive and
almost
"embedded" syntax at at premium. A very different approach from
"> On Behalf Of Jeff Garland those
you discuss, but in fact complementary and can be merged with other approaches.
As someone who has used odbc, jdbc, dbtools, sqlapi, otl, occi, etc., this looks very nice to me. Further, the relative simplicity suggests it would be straightforward to implement for the leading databases.
Jeff Garland Writes:
I've added a page to the Wiki to record this discussion -- feel free to add your thoughts on the basic requirements there... "
Thank you Jeff for setting that up. I just added " 5) Does not require the usage of RTTI 6) Allows for the user of the library to "plug in" thier own binding \ subscription system. (to support bound controls) "
On Fri, 22 Oct 2004 15:07:46 -0600, Brian Braatz wrote
Thank you Jeff for setting that up.
I just added
I moved your thoughts to the main page of discussion -- somehow you wound up on a closely related, but not the same name page... http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Relational_Da...
5) Does not require the usage of RTTI
Why? This seems like an arbitrary restriction to me. Further, for some dynamic query capabilities it seems like it would be a good way to implement the needed fuctionality. Of course for simple static SQL it wouldn't be needed.
6) Allows for the user of the library to "plug in" thier own binding \ subscription system. (to support bound controls) "
Can you clarify what you mean by 'bound controls'? Jeff
Jeff Garland wrote:
On Fri, 22 Oct 2004 15:07:46 -0600, Brian Braatz wrote [...]
6) Allows for the user of the library to "plug in" thier own binding \ subscription system. (to support bound controls) "
Can you clarify what you mean by 'bound controls'?
I assume he means a visual control that automagically reflects an underlying dataset (and updates it when the control gets updated). Dave
Jeff Garland wrote:
I moved your thoughts to the main page of discussion -- somehow you wound up on a closely related, but not the same name page...
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Relational_Da...
I also noticed there is a "competing" page: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Relational_Da... Is it useful to have both?
6) Allows for the user of the library to "plug in" thier own binding \ subscription system. (to support bound controls) "
Can you clarify what you mean by 'bound controls'?
I second the requirement, but with different interpretation. I think it is good to have the possibility to difine bindings for user-defined datatypes. Specializing a given class template is one way to achieve this variation point and is consistent with how it is done in STL. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/
I would bet money (not much, but maybe a few dollars ;-) ) that the 2 pages came about because of a linewrap in the link. Sorry, I'm sure I screwed that up somewhere. Array binding, (by which I believe you mean "bulk row fetch") is available in ODBC. It can be done either as arrays of structs ("row-wise binding") or as arrays of columns ("column wise binding") While I like the SOCI interface, we need to port it over to ODBC. While Oracle is one of the major vendors, everyone supports ODBC. (Of course the process of "boostifying" it may end up reworking alot anyways.) There a fundamental design question, and how we answer it will probably affect much of the remaining design: Do we want to have the actual bound columns be member variable/fields of the recordset object, or do we want the client to declare them and bind with a pointer or reference? The first way is the most common, and doing it that way would result in a similar interface to ADO, mysqlcppapi, and many other libraries. However, it can also limit flexibility, and it may make it impossible to attain the same performance using the library as hand coding to the API. Or can we offer both? Tito Maciej Sobczak wrote:
Jeff Garland wrote:
I moved your thoughts to the main page of discussion -- somehow you wound up on a closely related, but not the same name page...
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Relational_Da...
I also noticed there is a "competing" page:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Relational_Da...
Is it useful to have both?
6) Allows for the user of the library to "plug in" thier own binding \ subscription system. (to support bound controls) "
Can you clarify what you mean by 'bound controls'?
I second the requirement, but with different interpretation. I think it is good to have the possibility to difine bindings for user-defined datatypes. Specializing a given class template is one way to achieve this variation point and is consistent with how it is done in STL.
Brian Braatz wrote:
I just added
" 5) Does not require the usage of RTTI
6) Allows for the user of the library to "plug in" thier own binding \ subscription system. (to support bound controls) "
It is also important to have a connection pooling and a statement pooling. Almost all modern databases support parse-bind-execute interface. Parsing of a statement can take a significant part of a total statement execution time. Having a pool of prepared statements increases performance twofold or threefold (at least with ORACLE). It is important to have a well-designed hierarchy of exceptions to map database-specific error codes because people will need to handle not just an error but either a constraint violation or a permission validation problem. Database independent sql generator would be an important part of a database framework because we will need to generate DDL statements with different syntax for different databases at least for regression testing purposes. Do not forget about the LOB data type :-) There are two major types of LOB data types: with a random access interface and with a sequential access interface. Supporting of a database-specific data types would be a plus. ORACLE users will ask you about ref-cursors anyway. Thanks. -- Sergey Sikorskiy
participants (6)
-
Brian Braatz -
David B. Held -
Jeff Garland -
Maciej Sobczak -
Sergey Sikorskiy -
Tito Villalobos