On 4/22/15 12:45 AM, Oliver Palmer wrote:
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.
oddly enough, using just the schema you have this issue seems to
reproduce. On SQLite, and not Postgresql. Which is completely weird
because the sorting of tables has nothing to do with the backend.
always a mystery how something that looks about as possible as all the
buildings being upside down one day, will become something very simple.
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 <http://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
<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
<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
<mailto:sqlalchemy+unsubscr...@googlegroups.com>.
To post to this group, send email to sqlalchemy@googlegroups.com
<mailto:sqlalchemy@googlegroups.com>.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
--
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.
