Hi.

I've been searching through the docs trying to figure out exactly what it is that the version tag does.

I am trying to create mappings for a legacy database with a ton of composite keys. Many of these are simply two columns, "ID" and "Rev" (for "Revision") as keys for a table. When I found out about the element tag, I thought that maybe I could use it to help bring the mapping back down to earth by just using ID as the key and Revision as part of the versioning scheme built in to NHibernate.

However, I'm not really sure exactly what it is the version tag does, and I was hoping for a pointer to documentation on this. The official documentation says...

http://www.hibernate.org/hib_docs/nhibe ... on-version

"The <version> element is optional and indicates that the table contains versioned data. This is particularly useful if you plan to use long transactions (see below)."

And to my luck, there is no concept of "long transaction" listed in the entirety of the document (that I could find).

Am I going down the correct path here, or in my many ID/REV key situation I'm pretty much stuck on composite keys?

Thanks in advanced.

You can use Version in your situation.

They aren't needed for long-running transactions.. just people might use them in that case.

They're great for optimistic locking in any situation and that could be what your current database is using them for, or was planning to use them for.

For example.

Joe and Sue both open record 2, revision 1.

Sue changes data and saves. With Version mapped to revision in NHibernate, NHibernate will increment revision to 2.

Joe changes data and saves. NHibernate includes Version in the where clause and so no data gets updated...

You'll need to account for this in your app to account for what should happen when Joe can't save his data (something as simple as telling him to refresh the record and try again or as complex as trying to merge the data and redisplaying to him to save with his changes), but what it's done, essentially, is implemented an optimistic locking scheme for you. Pessimistic locking would mean that Sue would have optained a lock on the record, even if she never actually bothered to update any data.

Note, none of this has to be 'long-running' and could have all taken place in a couple of seconds on a web page... long-running is in the eye of the beholder.

Ah, thank you.

Unfortunately, I see this as a mechanism to just update the actual row. Typically, the systems I use will create an entirely new row with an incremented revision number along with the change, so that there is still "older revisions" recorded in the database.

I don't believe that nhibernate would do something to this effect.

Thanks again.

Correct. You'll definately want to handle that with a composite key or a custom key object.... the second might be a lot nicer since it'll give you control over the incrementing, especially if it's a common pattern in your application.

version@unsaved-value is also helpful for when the id@unsaved-value isn't appropriate for a given id/generator@class (e.g., assigned).