On Apr 16, 2009, at 3:25 AM, dykang wrote:
>
> Are objects not marked as dirty on changes? Do you check each
> attribute
> of each object in the session on every flush? If this process has poor
> performance, doesn't autoflush suffer the same consequences?
I believe I probably overstated how "expensive" this would be. in
most cases, yes there's just a plain "dirty" flag for an instance.
autoflush is not expensive because we even propagate that "dirty" flag
up to a per-session flag so that autoflush usually only needs to check
one boolean. but the whole thing is built within a system that
knows how to "fall back" onto a per-attribute system in the case that
a mapper is using a so-called "mutable" attribute, which means you're
storing a mutable data structure of some kind in a column, usually
something being pickled (although in theory date objects could have
this behavior too) - for those we have to check each attribute against
what was loaded from the DB. we have flags that prevent that entire
check from happening if no "mutable" mappers are in use.
anyway, the loading of rows into object state is so performance
critical that just adding the callable for the "dirty flag but make
sure theres no mutable attributes, otherwise check those" would still
add overhead I'd rather not have, though I guess we'd do it once for
each object as it enters the load.
>
> Maybe I'm confused, but I'm pretty confident that there are valid
> reasons
> to allow for not choosing a stricter isolation level. It may be the
> case that
> I have to accept that I'm using a system that is not the SQLA target,
> but I don't believe a stricter isolation level is always a good thing.
you can choose a lower isolation level...SQLA's philosophy is about
making as much possible as is...possible. im proposing autoflush +
this flag, not enough ?
> In fact the postgresql documentation even states:
> "Since the cost of redoing complex transactions may be significant,
> this mode is recommended only when updating transactions contain logic
> sufficiently complex that they may give wrong answers in Read
> Committed mode."
well the "redoing operations within a transaction" thing is another
place where the unit ofwork is not very helpful , unless you use
SAVEPOINTS, since it can't retry portions of a failed flush.
supporting that would be non-trivial.
> One situation where the FOR UPDATE case could be different would be
> if the row were already loaded FOR UPDATE previously in this
> transaction.
> If this has already happened, we wouldn't even want to check if the
> row
> was dirty, we'd probably want to accept what what was in the identity
> map,
> since we already hold a lock on the row. I guess it's more different
> than I
> thought it would be.
right. i dont know if thats the right approach or not but it feels
kind of opinionated to me at the moment (obviously im not a big user
of SELECT...FOR UPDATE). i also wouldn't want to get into attaching
state to objects based on the usage of FOR UPDATE.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
