On Wed, Jun 10, 2009 at 11:22 PM, Gustavo Niemeyer <[email protected]>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:passw...@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
-- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
