Indeed, this is, IMHO, the biggest sticky problem with ADO and/or odbc integration. Taking care of the database specific stuff is exactly what odbc DOES NOT do. The code we are working on now is specific to using odbc or ADO to access a Microsoft SQL database. If some poor unfortunate user were to try using the same code to get to (for example) an ACCESS database, things would mysteriously start to break. And what happens if we DO open a postgress or MySQL database using ADO? The code which already knows how to handle those database will not be called! The storm.database.register_scheme(scheme, factory) design is simply not capable of handeling the complexities involved in a user (or programmer) friendly way. The idea that each scheme uses a single specific api implementation to get to a single specific database server engine will not hold up in the real world. For example, if I access a MS-SQL database using adodbapi, I use qmark parameter substitution. To get to the same database using the Linux odbc driver, I must switch to the %s variety of parameters. Storm would have to know this. Am I supposed to (in my python application program) ask which operating system I am running on in order to use a different scheme? I think we can do better, but I am not sure how. Perhaps we will need to implement some sort of environment layer -- sort of like sys.path() -- in order to smooth this whole mess out. -- Vernon Cole
On Fri, Mar 6, 2009 at 2:11 PM, James Henstridge <[email protected]> wrote: > On Fri, Mar 6, 2009 at 3:36 PM, Martin DeMello <[email protected]> > wrote: > > On Sat, Mar 7, 2009 at 1:09 AM, James Henstridge <[email protected]> > wrote: > >> > >> Note that there is database specific code for all three currently > >> supported databases, so it is very unlikely that a new backend could > >> be done without similar work. > >> > >> This also means that a generic "pyodbc" backend is not on the cards: > >> it would depend on what database is actually being talked to. > >> > >> It probably wouldn't be a huge effort to support PostgreSQL or MySQL > >> through pyodbc, but I'd guess that isn't what Martin is after. > > > > I was hoping that the various database's ODBC drivers would take care > > of the database-specific stuff, and allow storm to access a common > > API, as long as I didn't want to do anything too funky (just need > > simple inserts, selects, updates and deletes, for the most part). > > I suppose the most important thing Storm does in the database specific > code is retrieving automatically assigned primary keys for newly > inserted rows in the database. This is something that even the > simplest Storm apps tend to rely on, so needs to be handled correctly. > > There are a few other bits and pieces, but that is the most important one. > > James. > > -- > storm mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/storm >
-- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
