Hallo,

ich nutze das version Element in meiner Mapping Datei (mitunter lange Transaktionen):
<version name="last_update" column="last_update" type="timestamp" />
und in der Bean entsprechend: private Timestamp last_update;

Beim erstmaligen Abspeichern kann ich das last_update frei definieren und es wird auch so abgespeichert.
Wenn ich das element später nun lade, editiere (irgendwelche Textfelder plus Datum) und per session.update(product) abspeichere nimmt er immer das aktuelle Datum in der Update Anweisung und nicht das was ich ihm via product.setLast_update(date) zuweise.

Beispiel: Titel geändert und Datum auf 15.8.

Hibernate macht da:
update products set last_update='2005-08-22 21:51:53.828', name='Schaukelstuhl' where globalid='abc123' and
last_update='2005-08-10 21:49:30.406'

und nicht:
update products set last_update='2005-08-15 12:00:00.000', name='Schaukelstuhl' where globalid='abc123' and
last_update='2005-08-10 21:49:30.406'

Ist das Hibernate Standardverhalten? Kann man das irgendwie beeinflussen?

Dann probierte ich statt update(product) noch:
replicate(product, ReplicationMode.OVERWRITE);

Auch hier das gleiche Verhalten. Hier hätte ich aber auf alle Fälle erwartet, dass das gesetzte Datum übernommen wird. So sind dann Ursprungs und Zielobjekt nicht identisch und die Bedeutung replicate ist irreführend.

Antworten wären dankend entgegengenommen!

Grüsse
Detlev

Hibernate version: 3.0.5
Name and version of the database you are using: HSQL

Hi,

wieso willst Du denn die Version per Hand anpassen? Sie dient ja "nur" dazu, dass optimistic lock zu vereinfachen. Das würde ich Hibernate überlassen.
Ich sehe das versions-feld immer als etwas an, was ich eigentlich gar nicht habe. Brauche ich also Zusatzinformationen (z.B. einen Timestamp) dann lege ich dafür ein neues Feld an, weil sich dann auch eine Fachlichkeit dahinter verbirgt. Das Versionsfeld überlasse ich ganz Hibernate und kümmere mich nicht drum.

Btw. finde ich ein "timestamp" als Versionsfeld eher ungeeignet, da es durchaus sein kann, dass mehere Benutzer zur gleichen Zeit (bis zu den ms) den gleichen Datensatz speichern ... gut, die Wahrscheinlichkeit ist recht gering, aber sie ist halt da.

gtx
curio

Hallo,

danke für dein Posting!

Der Hintergrund bei mir ist der, dass mehrere Nutzer lokale Datenbestände haben und diese mit einer zentralen Datenbank abgleichen. Dazu dienen Web Services welche u.a. den lokalen Timestamp übermitteln. Wenn nun in der Datenbank ein Objekt vom 1.8. existiert und der Client via Web Services am 3.8. das selbe Objekt aber mit einem Timestamp vom 2.8. zur Synchronisation übergibt, sollte schon der 2.8 erhalten bleiben. Das erleichtert das Handling, da sonst der Client auch unnütz aktualisiert werden müsste (auf 3.8. = Datum der Synchronisation).

Ich werde wohl auf das version Element dann verzichten müssen.

Grüsse
Detlev

wie gesagt ... für mich dient das versions-feld lediglich dazu, dass HB erkennen kann wann die letzte Änderung an den Daten stattgefunden hat (egal ob da "client" oder "server"-Zeit verwendet wird. Hauptsache immer gleich) und ob ein anderer Prozess die Daten "vor mir" geändert hat. Und da durchaus mehrere Prozesse zur gleichen Zeit Daten ändern können, verwende ich dazu auch kein Timestamp.

Auf ein Versionsfeld würde ich nicht verzichten, da sonst das optimistic lock handling "schwerer" wird ...
Der Strategie "letztes update gewinnt" oder "pessimistic lock mit Web-Services" kann ich irgendwie wenig abgewinnen ;)

gtx
curio