On Sep 29, 2008, at 9:30 AM, Alex K wrote:
>
> Hi All,
>
> My application uses XML schema to load tables, classes, set SQLA
> mapping and relations.
>
> Each processing node (thread or process, depends on config) does not
> know beforehand what type of mapping it will process, that's why I
> need to create mapping (parse schema, and generate classes) per each
> request.
>
> This approach worked fine for me, however I have issues when there is
> high load on the same processing node - SQLA throws an exception
> saying that my dynamic class is not mapped. ("Class app.User is not
> mapped")
>
> I understand that it may be some app/configuration issue (and I'm
> almost sure it is).
>
> Docs say that mapping should be created only at the app level, I
> thought that violating this rule can cause errors of this kind.
OK, what we mean more specifically there is that the mapper is created
in the same scope as the class. If you are creating classes local to
a function, you can create the mapper there as well.
That you have issues during "high load" is suspect, however.
> I thought that clear_mappers can help here, but I fear it will clear
> all mappers in the process, since _mapper_registry is a module level
> global hash.
this is correct. I wouldn't use clear_mappers here. If your
classes fall out of scope and are garbage collected, the corresponding
mappings should also fall out of scope, *provided no remaining mappers
reference them*. This behavior is also tested more fully in 0.5 and
I can't guarantee the "automatic garbage collection" as strongly in 0.4.
The overall idea of removing partial sets of mapped classes from a
larger group is not something we've tested or tried to support. It
wont work, for example, if you leave a mapper in place which is parent
mapper of one of the removed mappers, or if the remaining mapper has
relations to the removed mapper. The results are not defined in
those cases.
Another nasty side effect is that the "compile" phase of mappers is
globally mutexed. If you're creating mappings per request, the
compilation stage is mutexted against all other requests. This is
all a product of the fact that mappings deal with a global registry.
Additionally, since mapper compilation is only meant to occur once per
application, its not at all optimized for per-request performance and
will make for a slightly more sluggish application if called constantly.
It wouldn't be very difficult for the ORM to work using a Pylons-like
"stacked object proxy" approach where the mapper registry and its
mutex are swapped in and out on a per-request basis but its not clear
right now that this is something that should be built in.
The most unclear aspect of this, to me, is why you need to "drop"
anything at all. It seems that the incoming XML schema defines a set
of tables to be worked with. Certainly, the number of tables which
an instance of your application uses is fixed. It seems like it
would be very easy to just check the XML schema's identifier and look
up in a dictionary that this set of mappings has already been
defined. You'd have none of the issues related to clearing partial
mappings and you wouldn't have the enormous overhead of parsing
schemas and recompiling a set of mappers on every request.
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
