Ramsey is right. There are lots of pitfalls.
Losing FK constraints is a pain and I miss it, but it's something I can deal with … not ideal, but not a killer.
Reassigning IDs and merging data is the biggest problem and we are helped by the fact that most of our data comes to us and is loaded from a serialized form… so we just do that on the rare occasions we have to migrate some data. That bit of gymnastics has the side benefit of being able to move small chunks of data through the serialization instead of doing an entire db.
So far we haven't run into the situation of relating DB1 to DB2 primarily because the client databases are separate by policy and necessity. The scope of the data should never be seen between databases. That's a policy thing that helps us avoid that problem.
public void setEMRDatabaseConnection(Center c) throws MalformedURLException {
if (getEc().userInfo().containsKey("db")
&& getEc().userInfoForKey("db").equals(c.db())) {
logger.info("keeping connection to " + c.db() + " for center "
+ c.name());
} else {
ec.dispose();
ec = null;
ec = ERXEC.newEditingContext();
logger.info("connecting to " + c.db() + " for center " + c.name());
Object[] args = { c.host(), c.db() };
String url = "" style="color: #0326cc">URL_FORMAT, args);
NSMutableDictionary<String, String> cdict = new NSMutableDictionary<String, String>();
cdict.takeValueForKey(url, "URL");
ERXEOAccessUtilities
.closeDatabaseConnections((EOObjectStoreCoordinator) this.getEc()
.rootObjectStore());
EOUtilities.connectWithModelNamed(this.getEc(),
GenerateManagmentReports.EMR_MODEL_NAME, cdict);
getEc().setUserInfoForKey(c.db(), "db");
getEc().setUserInfoForKey(c.host(), "host");
getEc().setFetchTimestamp(System.currentTimeMillis());
ec.invalidateAllObjects();
getEc().refreshAllObjects();
}
}
I get a bit draconian in trying to make sure the editing context is fresh and clean, but this is the general idea for connecting to the database that is specific to the "Center"