Hi, > For me, at least, "solid" and "passes all tests" are not necessarily > the same thing....
This depends somewhat on your definition of "solid". In terms of volumns, I think you're absolutely right, if your basic operation works, you can process millions of rows and it doesn't matter that other unit tests fail. In terms of "all the features working" I've found the unit tests much more important. Over the last six months I've built quite a complicated app that using SQLAlchemy on MSSQL. What I found early on was that I'd often hit SA bugs as I coded up features. The unpredictability was quite a nightmare, and this is what motivated me to get all the unit tests passing. I've found that most of the failing tests are fixable problems. MSSQL has a few quirks, the IDENTITY columns (they're just like AUTONUMBER) being the main culprit. Just about the only feature it doesn't support is LIMIT with an offset; everything else works. And I've recently realised that this behaviour could be emulated by seeking the cursor. And with pyODBC and server-side cursors, this would be reasonably efficient. Looking forward, my work on the MSSQL module is probably getting towards the end. With Michael Jahn's work on fixing the scope_identity() issue looking very promising, that only leaves two bugs I know about. Once those are fixed, I'm hoping we can have a 0.3.9 release and finally drop the experimental status. And one last thing, a little nuge for Rick, can you commit my patches in ticket #581 please. :-) Take care, Paul > > The issue I think likes more with the test suite than with MSSQL or > any of its connectors, and I just haven't really found the time to dig > into the underlying reasons, as the basics all work for me -- I use > pymssql with SA in a commercial application that processes millions of > rows per day with some really complex SQL, mixing ORM with SQL layer > operations, mixing transactions between ORM and the SQL layer, calling > database > functions and stored procedures and working with lots of different > datatypes, and the thing works fine. It runs under Pylons with Paste, > and stays up for weeks at a time. It's stable. It's solid. And yes, it > fails unit tests. > > Writing a comprehensive test suite for like six different database > engines is really, really difficult, because of all the various > feature sets involved. Trying to run that test suite on a database > that was more or less a late entry to the game, with three (count em!) > DB-API access modules, each with their own sets of annoying problems, > and then add the issue of crossing the Unix - WIndow DMZ, and I'm not > surprised we get test failures. > > I'll be working on getting pyodbc stable and supported on Unix over > the next weeks and months, but it's going to be a slow process that's > going to involve more adjusting of the tests than fixes to the MSSQL > module. In a fast-changing library like SA, that's difficult because > test changes are likely to break other databases and annoy the author ;-) > > What will help, at least a little is a buildbot that will run the > tests on Unix across a range of databases. I'm setting that up to run > from the Pylons buildbot master, which will watch SQLalchemy trunk > checkins. This way, when you make changes > for Windows, we can see their effects for Unix within a few minutes on all > databases. The > other thing that's going to have to happen is a pretty big effort to > straighten out dependancies on database feature sets in the unit > tests, and factor those out so we don't see spurious failures. > > So, if your acceptance criteria for SA + MSSQL is going to be "passes > all unit tests", then it's going to be a while before that happens. > But we will get there eventually. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---