Could it be I am not loading enough modules? Does "all modules" mean
all modules of the application, or all modules to map successfully?
yes the issue is very likely that more modules are being imported
within non-main threads, and more mappers are coming in. if you get
absolutely every mapper loaded up, then call compile_mappers() before
any threads spawn, this kind of problem shouldn't occur.
Hm, should this include the dynamic mappers? These mappers are run with
/request/ specific parameters - if a user requests to see data of a
certain "view", a select object (using the current view parameter value)
and a related class are generated, used and released. These mappers
/will/ come in with threads. So, if "absolutely every mapper" includes
the mappers to selectables this cannot be achieved I fear ...
Until now, I understood we should run all our standard mappers (to
tables), finally run compile_mappers(), and could start the request
handler cycle (with threaded handlers and new mappers produced "on
request") afterwards.
There may be other bugs in mapper configuration in 0.5 though this
seems quite unusual that you're getting threading errors this
frequently (especially dictionary changed size ? stack trace on
that
?) .
I will try to produce a stack trace. (In the last instrumented debug
versions, I caught all exceptions so the stack traces were not logged.)
Trying 0.6 at least might be worth it.
Just in case I could not describe clearly before how dynamic and
request specific the function generated mappings are: would 0.6 allow us
to use the pattern of dynamic mapping described above?
Thanks and regards
Jochen
--
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.
