As far as the MS SQL support is concerned, there are two versions. The most complete one, which is AFAIK used in a production environment, uses a proprietary ODBC interface. Therefore it cannot be tested in a generic manner. The other uses adodbapi, which is free and open source. I have been intending for some time to start a project to combine the two versions, which I assume will require some upgrades to adodbapi. For the present moment, I am working on another project, which is django support in adodbapi. (Python 3 and IronPython support is complete.) Since storm and django are already intertwined, work on one implies work on the other. At the present moment, the django community is actively moving toward both IronPython and Python 3, so that seemed to be the priority. The storm community seems to be pretty happy with Python 2 and CPython for the moment, so a multi-version db api is not high on their list. When, eventually, storm and adodbapi work together, it may throw a wrench into the works... At present, each storm database back end uses one db api adapter and one dialect of SQL. The perception is that ADO is used for MS SQL only. Not so. ADO could be used to replace any of the existing db api adapters (except for sqlite). It CANNOT take care of the differences in SQL dialects. If the maintainers of the existing back ends start making steps to isolate the language differences from the interface differences, it will make things a lot easier when storm is ported to new environments. Perhaps the Oracle and MS SQL back ends could take the lead in this. -- Vernon Cole <div class="gmail_quote">On Sat, Nov 28, 2009 at 7:25 PM, Jamu Kakar <<a href="mailto:jkakar@kakar.ca">jkakar@kakar.ca</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi, A number of people on this list have been contributing to branches that add support for Oracle (and MSSQL 2005, but the looks of it) to Storm. This is really exciting, and I'd like to help get these branches into trunk and part of our official releases. That said, I'm not really sure exactly what's required to do this, so the purpose of this conversation is to come up with a list of tasks that need to be done to get this code landed. Here's the list of things I think need to be done. Please add missing items or correct me if I'm mistaken: - It's not clear which Oracle branch(es) need to be reviewed. I've taken a quick peek at lp:~zeomega/storm/zeomega_storm and it looks like it's fairly complete. Before diving in an doing a thorough review, can someone involved with the work please confirm that this is the right place to look and that this is where we should focus review attention? - What needs to be done to prepare an environment that can be used to run the test suite and exercise the changes made for these new backends? Ideally, the instructions will come in the form of a patch to the README file, since it already contains setup instructions that describe the setup needed to run test for the existing supported backends. - Have all contributors to the branches that are intended to land signed Canonical's contributor agreement? If not, that will be required before the code can be accepted. If there's any problem with this, please speak up now so that we don't spend time reviewing code that won't be accepted. Have I missed anything? Thanks, J. -- storm mailing list <a href="mailto:storm@lists.canonical.com">storm@lists.canonical.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/storm" target="_blank">https://lists.ubuntu.com/mailman/listinfo/storm</a> </blockquote></div>