SQLA execution error when running Pyramid tests

[Benjamin Sims]

I have an application which in one of its schema files issues an SQLA query:

def helper():

    return DBSession.query(User).all()

I also have some tests which test some elements around the model interactions and that their functions respond correctly. The setup() for these tests create an in-memory database to work with.

The problem I am now having is that my tests will now fail, giving the good old:

sqlalchemy.exc.UnboundExecutionError: Could not locate a bind configured on SQL expression or this Session

on the grounds that there is no bind for DBSession in helper() above. I understand that there is no bind, but helper is not called explicitly nor required by anything in the tests.

I understand I have misunderstood something in the way that the project/tests should be organised - could anybody point me in the right direction?

Thanks,

Ben

[Mike Orr]

On Fri, Mar 2, 2012 at 3:16 AM, Benjamin Sims <benjam...@gmail.com> wrote:
> on the grounds that there is no bind for DBSession in helper() above. I
> understand that there is no bind, but helper is not called explicitly nor
> required by anything in the tests.

Does the traceback say who called helper()? What happens if you
comment out the helper function?

--
Mike Orr <slugg...@gmail.com>

[Benjamin Sims]

Thanks for the help,

Relevant section of the traceback is as follows: 

File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/loader.py", line 91, in loadTestsFromName

    module = __import__('.'.join(parts_copy))

  File "/Users/benjamin/Project/app/dev/Project/project/schemas.py", line 171, in <module>

    class TheSchema(colander.Schema):

  File "/Users/benjamin/Project/app/dev/Project/project/schemas.py", line 176, in TheSchema

    widget = deform.widget.SelectWidget(values=helper()),

  File "/Users/benjamin/Project/app/dev/Project/project/schemas.py", line 168, in helper

    # SQLA query is done here

It seems that the unittest loader is loading the schema class as one of its tests, which then makes the helper call and fails.

Commenting out the TheSchema class allows the test to run as normal. 

Thanks,

Ben

--
Mike Orr <slugg...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.

[Mike Orr]

So Deform is trying to resolve a table schema at import. I don't know
about Deform schemas, but what's probably happening is that with
pserve, the engine is configured and bound before the view scan is
called, but in the test environment it's importing the model looking
for tests, and thus triggering the code before main() has been called.
This often happens in unit tests, in Pylons and other frameworks. The
general solution is to move the code into a function or arrange for
that module not to be scanned, but I don't know how to apply this to
Deform.

--
Mike Orr <slugg...@gmail.com>

[Benjamin Sims]

I'm not sure specifically why it would be triggered (not experienced this before with other projects using Deform).

In any case, I was able to solve by refining the test suite setting in setup.py, specifing myproject.tests rather than just myproject.

Thanks,

Ben

[Atsushi Odagiri]

Hi

I have some question for this problem.

when do you call `sqlahelper.add_engine`?

and don't you call `sqlahelper.reset`?

if you call `sqlahelper.reset`, and you must reload `models` module.

regards

2012/3/6 Benjamin Sims <benjam...@gmail.com>

--
/*
Atsushi Odagiri
http://blog.aodag.jp
mailto:aod...@gmail.com
*/

[Mike Orr]

``sqlahelper.reset()`` exists mainly for SQLAHelper's own unit tests.
I don't know whether it's appropriate for Pyramid app tests. I can
clarify this in the documentation if we decide one way or the other.

I wonder if Pyramid needs a Nose plugin like Pylons does, so that
--with-pylons=test.ini loads a configuration that sets the db binding
globally, so that it doesn't have to be set for each test.

[Benjamin Sims]

Yes, in my case I deal with the database connection in the unit test setUp() and don't touch sqlahelper.

To my mind the issue was why the code was being called - it was not under test.

Ben