I have a desktop (winforms) application that uses a Firebird database as a data store (in embedded mode) and I use NHibernate for ORM. One of the functions we need to support is to be able to import / export groups of data to/from an external file. Currently, this external file is also a database with the same schema as the main database.
I’ve already got NHibernate set up to look at multiple databases and I can work with two databases at the same time. The problem, however, is copying data between the two databases. I have two copy strategies: (1) copy with all the same IDs for objects [aka import/export] and (2) copy with mostly new IDs [aka duplicate / copy]. I say ‘mostly new’ because there are some lookup items that will always be copied with the same ID.
Copying everything with new IDs is fine, because I’ll just have a ‘CopyForExport’ method that can create copies of everything and not assign new IDs (or wipe out all the IDs in the object tree).
What is the ‘best practices’ way to handle this situation and to copy data between databases while keeping the same IDs?
Clarification: I’m not trying to synchronize two databases, just exporting a subset (user-selectable) or data for transfer to someone else (who will then import the subset of data into their own database).
Further Clarification: I think I’ve isolated the problem down to this: I want to use the ISession.SaveOrUpdate feature of NHibernate, so I set up my entities with an identity generator that isn’t ‘assigned’. However, I have a problem when I want to override the generated identity (for copying data between multiple databases in the same process).
Is there a way to use a Guid.Comb or UUID generator, but be able to sometimes specify my own identifier (for transferring to a different database connection with the same schema).
I found the answer to my own question: The key is the ISession.Replicate method. This allows you to copy object graphs between data stores and keep the same identifier. To create new identifiers, I think I can use ISession.Merge, but I still have to verify this.
There are a few caveats though: my test class has a reference to the parent object (many-to-one relationship) and I had to make the class non-lazy-loading to get Replicate to work properly. If I didn’t have it set to eager load (non lazy load I guess), it would only replicate the object and not the parent object (cascade=’all’ in my hbm.xml file).
The java Hibernate docs have a reference to Replicate(), but the NHibernate documentation doesn’t (section 10.9 in the java docs).
This makes sense for the Replicate behavior because we want to have fully hydrated entities before transferring them to another data store. What’s weird though is that even with both sessions open (one to each data store), it didn’t think to hydrate the object when I wanted to replicate it.