Hello Michael,
JFYI - schema mapping approach worked fine, however I faced a new
requirement to clear mappings in case if schema was altered (since I
can not restart the web server),
so I will try to clear partial mappers as you've suggested,
Alex
On 29 сент, 18:35, Alex K <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
