[storm] Moving Storm Forward

[Vernon Cole]

On Wed, Jun 10, 2009 at 11:22 PM, Gustavo Niemeyer <gustavo at niemeyer.net>wrote:

> > Project scope is what worries me about my own hopes (or is it dreams?)
> for
> > Storm.
>
> Supporting new databases is well within the wishes we have for the
> project, so you can continue dreaming about it, and maybe they'll even
> become reality at some point.
>
> > My "best" solution so far is to:
> >   1) finish making Storm work on adodbapi on Windows
> >   2) make a fork of adodbapi which will run on ado.NET using IronPython.
> >   3) make Storm work on that platform
> >   4) port adodbapi to IronPython on Mono on Linux.
> >   5) make Storm work on that platform
> >
> > I think you will agree that is a very large scope.
>
> It actually doesn't look like a *lot* of work, once the basics are in
> place.  If we make Storm work with adodbapi, I'd expect that getting
> it to work with the other platforms should be a matter of tweaking it
> up, rather than a massive amount of work.
>

True, each increment is a reasonable step, and I for one would like to
pursue the project. ZeOmega has step 1 pretty much done, as far as MS-SQL is
concerned.

My worry is what happens when I hook to something OTHER than MS-SQL using my
ADO connection? There are a lot of [insert shudder here] Access (a.k.a, Jet)
databases out there, can we include them? I already test adodbapi against
Access, MS-SQL, and MySQL and am planning on adding Postgress tests. Can we
add complexity to the internals of Storm to allow using ADO to access those?
How to I clue Storm to use ADO to access different engines? Will I use
'ado-MySQL://dbname' vs 'ado-msSQL://db' vs 'ado-Access://filePath')? Will I
have to change my create_database argument to switch between different
drivers for the same engine?

All of these concerns point to making create_database more complex than it
now is: so that it can do logical mapping of "scheme:" to different database
engines. - - - While we are in that neighborhood, I want to able to
virtualize the entire "scheme://username:password@hostname:port/database_name"
construct so that I can deliver programs to customers who use different
engines, usernames, passwords, hosts, ports, and database names, without
modifying the source code. [ I am stuck on that idea because I have been
using a database system which does that really well (RDM) for the past 28
years. Perhaps there is a better way?]

I mention that here, rather than filing a Bug, because there needs to be
open discussion about how to go about it. This is a big design question. The
existing design of "we support three schemes, if you want another scheme,
write a module with  the correct name" is simple and effective. ADO fouls up
the works. If that simplicity is to be lost, the change needs to be done
right, if it is to be worth the cost.
--
Vernon Cole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/storm/attachments/20090611/a67a48ba/attachment.htm