On 2 Jun., 18:22, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Jun 2, 2008, at 11:55 AM, Nebur wrote:
>
>
> so....since these objects are returned by create_instance(), that
> means they are getting sent straight into a Session. I'm assuming you
> didn't write your own Session, so what happens when the
> populate_instance() step gets run on the objects , and several
> concurrent threads are all issuing populate_instance() on those items
There are more places where multiple threads would fail. E.g. caching
the instances.
The concerned web app will not use multiple threads (but single-
threaded processes only.) So, a threadsafe pattern was simply not
intended.
I should have placed this prerequisite prominently above the recipe.
> modifications. Similarly, I dont see how very basic functions
> necessary for SQLA's operation, such as object_session(), can possibly
> work correctly here, since you are attempting to place the same object
> in multiple sessions - an object's session is identified by a single
> attribute placed upon the object's state (in 0.4 its on the object
> itself).
>
> Unless your app is using only one Session. Then it could work,
It's ensured that there won't be two or more sessions same time.
(Beside that, I do _not_ want to enforce a session to live long; I
think that's not the intention of an ORM session.
I've assumed that generally, an application better should not depend
on very long-living sessions, althought it might be technically
possible. So, the sessions will change but strictly sequentially and
not overlapping.)
> If there is some central core of "state" that you dont want to
> replicate, it's still possible to have many copies of an object all
> reference that same state using a proxying pattern. As far as hash
> identity, the __hash__() and __cmp__() methods work fine in that
> regard.
Yes, another approach would be accepting copies of the immutable
objects with appropriate hash values.
The question was: which version does represent the "real world" best ?
I think in the case of immutable (readonly) objects, representing
these as long-living instances does look adequate. These objects
would change states between persistant and detached when bound and
unbound with subsequent sessions.
Of course, what I want to clearify is: Are long-living objects a
design "against the ORM" ? Is the subsequent change between persistent
and detached state an "anti pattern" (even if we can make it work) ?
Obviously, there's nothing wrong with detached instances that get
persistent again, as the docs say. But here, I'm aware that the
objects to not take the usual "session.update()" way.
If this is against the ORM intention, or in some unspecified "grey
area", I'd clearly withdraw the pattern. Otherwise, i'd prefer the
pattern since it seems to picture the "real world" well (and even does
substantiate this by simplfying tasks in different places.)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
