Thanks for such a detailed response!
I'll try schema caching approach and will bring back the results,
Thanks again,
Alex
On 29 сент, 18:21, Michael Bayer <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
