Hi all, I was finally able to spend a little time on the Firebird backend, and I'm glad to say that I'm currently down to this test summary:
Ran 1030 tests in 63.169s FAILED (failures=7, errors=187) There are still some real issue, but most of the failures and errors come from a few common patterns: A. some tests do a textual comparison against an expected statement; this breaks on FB, because the dialect inserts an explicit PK field:: AssertionError: Testing for query 'INSERT INTO users (user_name) VALUES (?)' params [{'user_name': 'thesub'}], received 'INSERT INTO users (user_id, user_name) VALUES (?, ?)' with params [{'user_name': 'thesub', 'user_id': 1}] five of the above seven failures are of this kind :) B. many other tests insert an explicit NULL in a PK field, not allowed under Firebird (because PK fields *must* be NOT NULL) most of the above 187 errors fall in this category. C. a few tests don't use an explicit ordering, and assume that the result of a select without an "ORDER BY" matches the insert order; under Firebird I notice an intermittent behaviour, and in some cases (expecially under load) this is not true. The following fixes one of those points to explain:: Index: test/engine/execute.py =================================================================== --- test/engine/execute.py (revisione 3952) +++ test/engine/execute.py (copia locale) @@ -26,7 +26,7 @@ conn.execute("insert into users (user_id, user_name) values (?, ?)", [3,"ed"], [4,"horse"]) conn.execute("insert into users (user_id, user_name) values (?, ?)", (5,"barney"), (6,"donkey")) conn.execute("insert into users (user_id, user_name) values (?, ?)", 7, 'sally') - res = conn.execute("select * from users") + res = conn.execute("select * from users order by user_id") assert res.fetchall() == [(1, "jack"), (2, "fred"), (3, "ed"), (4, "horse"), (5, "barney"), (6, "donkey"), (7, 'sally')] conn.execute("delete from users") D. to my surprise, a self-reference foreign key on a table needs either "ON DELETE CASCADE" or "ON DELETE SET NULL" to allow the testsuite to delete its content in the tearDown step with a simple "DELETE FROM table" statement; one spot of this is fixed by the following:: Index: test/orm/eager_relations.py =================================================================== --- test/orm/eager_relations.py (revisione 3952) +++ test/orm/eager_relations.py (copia locale) @@ -650,7 +650,7 @@ global nodes nodes = Table('nodes', metadata, Column('id', Integer, Sequence('node_id_seq', optional=True), primary_key=True), - Column('parent_id', Integer, ForeignKey('nodes.id')), + Column('parent_id', Integer, ForeignKey('nodes.id', onupdate="CASCADE", ondelete="CASCADE")), Column('data', String(30))) @testing.fails_on('maxdb') I don't care so much about As because it's clearly an annoying problem to cure: hopefully those stmts are going to be exercised for real... Bs annoy too, and void the effectiveness of several tests. I'd like to correct the last two points, because otherwise important tests fail for different reasons than the test expects to trigger, masquerading real issues. For Ds, I understand that not all DBs handle that kind of FK.... so maybe those backend could ignore "onupdate"/"ondelete"? What do you think? Thank you, ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. [EMAIL PROTECTED] | -- Fortunato Depero, 1929. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---