Ok then i will try to explain it:
I have a pylons web application... and i want to use the entity
attribute updated_at as a Datetime version_id...
so i modified the entity with the mapper args and put a hidden input
field in my edit html forms for the updated_at value... in order to
preserve it... i got this idea from some newsgroup some days ago... i
don't remember exactly where...
this approach is quite simpler, than saving the state respectively the
entity object to an http session... or any other smaller server-side
context... like in jee
another point is... i think this wouldn't be possible with pylons...
because of the serialization of objects saved to the http session
object... i remember to have read something like this about pylons...
so if the user commits the form i take all input values and set them at
an entity object. This entity object is not attached to the unit of work
(i think it is called like this in sqlalchemy?) but it will get attached
at the moment, when i call session.merge(item) (at least this is what
the documentation says)... i only want to clarify this?!
so the behavior i need is, that the manually set version_id is used to
identify the record in the database table... during the update... and
with version >= 0.6.4 this does not work... maybe it works with an
extremely complex configuration... but i don't know which one this
should be...
furthermore it is necessary that the manually set version_id is newly
generated by version_id_generator for the update statement... because
the intention of version_id during update is not to be set manually...
but to be generated over and over again... i cannot think of a scenario
where this shouldn't be the intended behavior?! because the version_id
is a completely managed attribute... it doesn't make any sense to really
set it manually and flush this to the db...
maybe you can clarify in which way the version_id_col should behave? and
which session configuration has to be used?
i use thread-local sqlalchemy sessions and remove those at the end of
every request... just like the pylons doc recommends:
Session = scoped_session(sessionmaker(autocommit=False,
expire_on_commit=False))
i don't know if expire_on_commit has necessarily to be False... i tested
it with True and False... during 0.6.4 and 0.6.6 and nothing changed.
autocommit is False with default behavior... but i thought... just in
case ;-)
so ... these are my thoughts about version_id_col ...
it works really fine now... with 0.6.3 ;-)
and thanks for the great orm :)
Greetings
Jan
On 01/17/2011 01:17 AM, Michael Bayer wrote:
if there's a bug in version_id_col I'd really like to know. I don't
understand the use case for setting the column explicitly, then having it not
persist.
On Jan 16, 2011, at 7:11 PM, Jan Mueller wrote:
I switched to 0.6.3 and version_id_col works... just like i expected... that's
really odd...
i guess i will stay at this version and everything will be fine ;-)
thank you very much.
and sorry for the lacky explanation of my problem.
Greetings
Jan
--
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.
--
Jan Müller
Liebigstr. 66
35392 Gießen
Mobil ::: 0151 54825335
Festnetz ::: 0641 39922885
Google Account ::: jan.marco.muel...@gmail.com
E-Mail ::: j...@it-gen.de
Jabber ::: j...@it-gen.de
Skype ::: jan.mueller1981
--
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.
