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
-~----------~----~----~----~------~----~------~--~---
