ConcurrentModificationError: Deleted rowcount 0 ... but only on mysql?
Ergo
of objects deleted...
I create my schema from models using create_all() - now , the problem
is i get this error only using mysql or mysql+oursql. It happens every
time in one place of my code.
But when i uses postgresql nothing bad happens and that exactly same
code and same models work without issues. Is it possible im hitting a
bug in sa here i did something wrong? Normally i would just assume i
did some mistake when mapping models, but on postgresql it works like
a charn... im a bit lost
Michael Bayer
On Aug 21, 2010, at 7:45 AM, Ergo wrote:
> ConcurrentModificationError: Deleted rowcount 0 does not match number
> of objects deleted...
for clarity, this error has been renamed to StaleDataError. Here is the docstring coming up in 0.6.4:
* A flush may have attempted to update or delete rows
and an unexpected number of rows were matched during
the UPDATE or DELETE statement. Note that when
version_id_col is used, rows in UPDATE or DELETE statements
are also matched against the current known version
identifier.
* A mapped object with version_id_col was refreshed,
and the version number coming back from the database does
not match that of the object itself.
>
> I create my schema from models using create_all() - now , the problem
> is i get this error only using mysql or mysql+oursql. It happens every
> time in one place of my code.
We have tests for cursor.rowcount that pass fully using OurSQL. Have you tried MySQL-python just to check that its not an OurSQL issue ,perhaps a newer or older version of OurSQL we haven't tested against is in use ? We would need code + oursql version that illustrates the issue being reproduced.
>
> But when i uses postgresql nothing bad happens and that exactly same
> code and same models work without issues. Is it possible im hitting a
> bug in sa here i did something wrong? Normally i would just assume i
> did some mistake when mapping models, but on postgresql it works like
> a charn... im a bit lost
>
> --
> You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
> To post to this group, send email to sqlal...@googlegroups.com.
> To unsubscribe from this group, send email to sqlalchemy+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
>
Ergo
Sorry Michael i was unclear on this - i tested on 4 drivers:
psycopg2,
pg8000,
mysql-python (1.2.3c1),
oursql (0.9.2)
mysql-connector (0.1.5)
on pg drivers everything works fine, on both on them, every single
mysql driver fails.
the problem is solvable by passing passive_deletes=True, to my
mappings, but as i understand - this is not a proper solution, and it
raises question why it works on pg drivers without issue.
If you want i can give you link to open source app where the problem
exists, its installable just by hg pull, and setup-app command for
tests.
Michael Bayer
On Aug 21, 2010, at 3:04 PM, Ergo wrote:
> Hi,
>
> Sorry Michael i was unclear on this - i tested on 4 drivers:
>
> psycopg2,
> pg8000,
> mysql-python (1.2.3c1),
> oursql (0.9.2)
> mysql-connector (0.1.5)
>
> on pg drivers everything works fine, on both on them, every single
> mysql driver fails.
>
> the problem is solvable by passing passive_deletes=True, to my
> mappings, but as i understand - this is not a proper solution, and it
> raises question why it works on pg drivers without issue.
If you have ON DELETE CASCADE configured on foreign keys and we are talking about a delete() that cascades to collections, its a good idea to have passive_deletes=True since that will save on loading up rows that would be automatically deleted anyway. I can't quite work out in my head how you'd be getting 0 rows deleted when it expects to delete N, but usually the difference here is that you aren't using InnoDB on your MySQL tables, so you dont get the nice FK behaviors every other DB gives you. Just a hunch.
>
> If you want i can give you link to open source app where the problem
> exists, its installable just by hg pull, and setup-app command for
> tests.
>
Ergo
forgot to define innodb in model definitions, and unfortunately that
didnt help anything.
I guess ill set passive_deletes to True, but it would be still good to
investigate further why this happens - since it seems a reasonable
assumption that the problem would surface with pg drivers too if it
would be something on my side ?
Michael Bayer
Its very unlikely. We've got dozens of tests for this kind of thing that have passed on all platforms for years - the ORM has no idea if PG or MySQL is in use and does nothing different. A DELETE is just a DELETE on all platforms.
MySQL has a lot of quirks, and I'd check that you in fact have InnoDB consistently in use, the same foreign key setup, stuff like that. It also could be some side effect of something upstream with primary keys or something. You'd need to work out an absolute minimum example case to distill out the issue before we'd have something to work with (please note example cases are a single script file, typically with no more than two or three mapped classes, no extraneous columns or imports needed, runs a full mapper setup, inserts sample data, illustrates the failure - fully self contained, succinct, and runnable).