Hello,
is there a problem in mapping classes to selects ([1]) /within a
function/? We are running into mapper errors reading
"InvalidRequestError: One or more mappers failed to compile.
Exception was probably suppressed within a hasattr() call. Message was:
One or more mappers failed to compile. Exception was probably
suppressed within a hasattr() call. Message was: 'Mapper' object has no
attribute '_props'"
when doing so and I could not find out why yet.
Here is our setup: we run a WSGI web application using Apache 2.2.14 in
MPM worker mode (a multi threading server configuration, see [2]),
Python 2.6.6, Werkzeug 0.5.1, SQLAlchemy 0.5.8 and SQLite 3 databases.
Standard tables are mapped as usual, ORM and expression language access
work well.
To provide "views" with variable parameters, additional "dynamic"
mappings are established on request, which means by a function. Here is
a simplified example:
def get_view(param):
class DBG(object): pass
dbg = select([records.c.id],
records.c.checksum==param).alias('dbg')
mapper(DBG, dbg)
return (DBG, dbg)
The function provides the select object for use in expressions and the
class for ORM use, but the error continues to show up even if the
results are never used, as in
def some_function():
class DBG(object): pass
dbg = select([records.c.id]).alias('dbg')
mapper(DBG, dbg)
return something_else
The mapper is a wrapped version of SQLAlchemies standard wrapper. It
extends the given class, calls sqlalchemy.orm.mapper() and supplies the
result of that function call, a Mapper object. I suppose it can be
treated to be sqlalchemy.orm.mapper here for simplicity.
Now this works well in a (single threaded) local environment, but on
the web server the application can become unstable when the function is
invoked answering a request. Then, in /some/ subsequent request, the
error shown above can arise, which looks as if something is passed
through from one request to the other. It can take many requests until
this happens but once the error occurred more and more threads are
"infected" quickly (in a stress test scenario).
The differences I see between our standard mappings and those in this
function are that standard mappers are applied once, while the function
maps multiple times. The second difference is the use of selects instead
of tables. Do you see any problems here?
Is there a known problem with this setup, or where could I continue to
search to find the reason of this problem? Is there a better practice to
be followed?
(I searched for problems in session handling but it seems to me the
application follows the related instructions, using a scoped session and
calling session.remove() at the end of request handling.)
Thanks in advance!
Jochen
References:
[1]
http://docs.sqlalchemy.org/en/rel_0_7/orm/mapper_config.html#mapping-a-class-against-arbitrary-selects
[2] http://httpd.apache.org/docs/2.0/mod/worker.html
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
