Re: [sqlalchemy] Non backwards-compatible changes in 1.0? Lots of suddenly failing tests here.
We're using a Flask extension to work with sqlalchemy called flask-sqlalchemy. The engine is usually not directly exposed but echo can be enabled using a configuration var https://github.com/pyfarm/pyfarm-master/commit/5d0abc03273f0fcce3c7d2cf44ef8981dd31aa41 which should have the same impact in terms of logging the sql statements. This time around I only ran the tests for one module because we hit Travis's 4MB log limit in a couple of seconds when running all the tests at once. I can run the full test suite locally and upload that log output somewhere if you need it. Otherwise, here's the failures when using 3e80d628bd133d0fd0687e35b8d13abd1d31d6df (search for 'IntegrityError'): https://s3.amazonaws.com/archive.travis-ci.org/jobs/59494875/log.txt https://s3.amazonaws.com/archive.travis-ci.org/jobs/59494876/log.txt https://s3.amazonaws.com/archive.travis-ci.org/jobs/59494877/log.txt https://s3.amazonaws.com/archive.travis-ci.org/jobs/59494878/log.txt https://s3.amazonaws.com/archive.travis-ci.org/jobs/59494880/log.txt But, it also passed once too (like the test I did yesterday): https://s3.amazonaws.com/archive.travis-ci.org/jobs/59494879/log.txt All of the above are from this Travis job: https://travis-ci.org/pyfarm/pyfarm-master/builds/59494874 And with sqlalchemy 0.9.9. Same tests and logging configuration just consistently passing compared to the above: https://s3.amazonaws.com/archive.travis-ci.org/jobs/59494606/log.txt https://s3.amazonaws.com/archive.travis-ci.org/jobs/59494607/log.txt https://s3.amazonaws.com/archive.travis-ci.org/jobs/59494609/log.txt https://s3.amazonaws.com/archive.travis-ci.org/jobs/59494610/log.txt https://s3.amazonaws.com/archive.travis-ci.org/jobs/59494611/log.txt Here's the original Travis job for those: https://travis-ci.org/pyfarm/pyfarm-master/builds/59494605 By the way, thanks a bunch helping us taking a look at this. On Tuesday, April 21, 2015 at 11:42:30 AM UTC-4, Michael Bayer wrote: On 4/21/15 11:19 AM, Guido Winkelmann wrote: On Tuesday 21 April 2015 09:43:51 Mike Bayer wrote: On 4/21/15 6:45 AM, Guido Winkelmann wrote: On Monday 20 April 2015 21:57:40 Oliver Palmer wrote: [...] So I got to thinking about what we're doing differently with sqlite and this bit of code comes to mind: # sqlite specific configuration for development if db.engine.name == sqlite: @event.listens_for(Engine, connect) def set_sqlite_pragma(dbapi_connection, connection_record): cursor = dbapi_connection.cursor() cursor.execute(PRAGMA foreign_keys=ON) cursor.execute(PRAGMA synchronous=OFF) cursor.execute(PRAGMA journal_mode=MEMORY) cursor.close() If I comment the above out in our application.py https://github.com/pyfarm/pyfarm-master/blob/f22912cd7d89b93c146801fd1575 ff0 6f4883724/pyfarm/master/application.py#L208 module the second nosetests example above works without issues. This looks to me like you are fixing the problem by just not enabling foreign key support in sqlite. Since the problem was a foreign key violation, telling sqlite to not bother enforcing those will make it so we don't see the problem in the tests anymore, but it doesn't fix whatever is going on here... what is needed here is actual logging of the tables as they are being dropped. The claim here is that the ordering of the tables is wrong in 1.0.0. So can we please see the full list of DROP statements logged for both the 0.9.9 version and the 1.0.0 version? Can you help me with that? I don't know how to make SQLAlchemy log all its DROP statements. logging is through the standard Python logging system, or alternatively the echo=True flag on create_engine() as a shortcut, but for a travis build I'd imagine that logging and stdout might already be routed around. http://docs.sqlalchemy.org/en/rel_1_0/core/engines.html?highlight=logging#configuring-logging Guido W. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Non backwards-compatible changes in 1.0? Lots of suddenly failing tests here.
Hey original developer pyfarm-master here, Guido pointed me at this thread. I've run a test with a3af638e1a95d42075e25e874746 and the sqlite tests are still failing to drop the tables: https://travis-ci.org/pyfarm/pyfarm-master/builds/59341150 Since Guido commented however I merged a PR he proposed and that seems to have fixed most of our other failures (everything except for the drop tables issue with sqlite). I started to think there's something different with respect to sqlite and wrote this which does almost exactly what the tests do (and it always works): import os os.environ.update( PYFARM_DATABASE_URI=sqlite:///:memory: ) from pyfarm.master.application import db for i in range(5): # setUp from pyfarm.models.agent import Agent from pyfarm.models.job import Job from pyfarm.models.jobtype import JobType from pyfarm.models.software import ( Software, SoftwareVersion, JobSoftwareRequirement, JobTypeSoftwareRequirement) from pyfarm.models.tag import Tag from pyfarm.models.task import Task from pyfarm.models.user import User from pyfarm.models.jobqueue import JobQueue from pyfarm.models.gpu import GPU db.create_all() # execute tests # tearDown db.session.remove() db.drop_all() There's a gist of the above here for those who have issues displaying the above properly: https://gist.github.com/opalmer/0850879794e81198c3a0 If you run a test individually, it also always works: env PYFARM_DATABASE_URI=sqlite:///:memory: nosetests tests/test_models/test_model_users.py:UserTest.test_user_auth_token However if you run something that requires a few test iterations it almost always fails when dropping the tables: env PYFARM_DATABASE_URI=sqlite:///:memory: nosetests tests/test_models/test_model_users.py:UserTest I say almost always fails because on occasion the above will pass too. I'm only using the above test case as an example but other tests seem to have the same problem. So I got to thinking about what we're doing differently with sqlite and this bit of code comes to mind: # sqlite specific configuration for development if db.engine.name == sqlite: @event.listens_for(Engine, connect) def set_sqlite_pragma(dbapi_connection, connection_record): cursor = dbapi_connection.cursor() cursor.execute(PRAGMA foreign_keys=ON) cursor.execute(PRAGMA synchronous=OFF) cursor.execute(PRAGMA journal_mode=MEMORY) cursor.close() If I comment the above out in our application.py https://github.com/pyfarm/pyfarm-master/blob/f22912cd7d89b93c146801fd1575ff06f4883724/pyfarm/master/application.py#L208 module the second nosetests example above works without issues. Here's a test on travis with sqlalchemy 1.0.0 and the above code commented out: https://travis-ci.org/pyfarm/pyfarm-master/builds/59345110 And from the latest master (didn't expect a difference here but wanted to be sure): https://travis-ci.org/pyfarm/pyfarm-master/builds/59346659 And here's the same tests with the same code above commented out with sqlalchemy 0.9.9 https://travis-ci.org/pyfarm/pyfarm-master/builds/59346146 So I'm not sure yet if this is a bug in sqlalchemy 1.0.0+ or not because I didn't dive that deeply into the code changes for event handling. Regardless, I think this is probably something we should update in our tests anyway since we could couple the execution of those pragma statements more closely with the tests as they run to avoid the issue in the future. I would be curious to know if this is actually a bug in event handling though. ---Oliver On Monday, April 20, 2015 at 7:22:47 PM UTC-4, Michael Bayer wrote: On 4/20/15 12:56 PM, Guido Winkelmann wrote: I just tested, the problem is still present in the current master (bd61e7a3287079cf742f4df698bfe3628c090522 from github). Guido W. can you please try current master at least as of a3af638e1a95d42075e25e874746, thanks. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
