On Jan 16, 2011, at 1:20 PM, Jan Mueller wrote:
> Hi everybody,
>
> help...
>
> i need optimistic locking for some concurrently edited entities.
> I am experiencing some problems with the "version_id_col" feature. I wanted
> to use it with my pylons application, but it does not work at all.
> I use sqlalchemy 0.6.4 with sqlite (for developement purposes). My pylons app
> is fully functional except for the version_id_col feature. Here is my code in
> addition to my declarative entity classes:
>
> updated_at = Column(DateTime(), nullable=False, default=datetime.now)
> __mapper_args__ = {
> 'version_id_col': updated_at,
> 'version_id_generator': lambda v:datetime.now()
> }
>
> I read in the changes, that in this version the behavior of version_id_col
> was changed. You can not set the version_id_col manually!?
The enhancement in 0.6.4 is that the value of version_id_col *can* be changed
manually. This was not possible prior to 0.6.4 - whatever value would be
placed there would be overwritten on flush.
> If you do so, the value you set will be saved to the db... and thats exactly
> what happens, but how can i change this behavior?
Why would you set the value of a mapped attribute, then expect it not to be
persisted ? If you have an attribute that you don't want to be persisted,
don't map it to a database column.
If you'd like some local non-mapped attribute to have a default value of that
of your version col, use a descriptor that saves a local value, if not present
returns the mapped one.
class MyClass(object):
@property
def my_version_id(self):
return getattr(self, 'local_version_id', self.version_id)
@my_version_id.setter
def my_version_id(self, value):
self.local_version_id = value
> I guess in older versions it was possible to preserve the version through an
> hidden input field?!
I'm not sure what a "hidden input field" is in the context of generic Python
objects, but the descriptor example above might be what you're looking for.
> How can i use this feature, when the objects of the corresponding entity are
> going to be detached from the unit of work after every http request?
When the object is detached, whatever value was already present for version_id
remains on the object, unaffected, until you change it, or re-attach and
persist a new version of the object's state. The "feature" applies to how
the object is persisted (as does optimistic locking in general) so by
definition has nothing to do when the object is detached.
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
