IIRC, it is not handled.
On 2012-06-18, at 1:43 PM, Ramsey Gurley wrote: > Out of curiosity, do you happen to know if it's possible to run migrations > against multiple data stores like you have Larry? > > Ramsey > > On Jun 18, 2012, at 1:25 PM, Larry Mills-Gahl wrote: > >> I do have an app with a different database connection per session. This does >> appear to be relatively uncharted territory, but it has been working in >> production for a while and it has been working pretty well. This is not a >> high volume transactional application. >> >> I use two models in this setup. One is a common or application wide model >> and the other contains the data specific to the logged in user. The common >> model contains the information necessary to connect to databases based on >> state in the session. In my case, the database connection may change based >> on the authorizations of the logged in user (admins can change db >> connections for various purposes and it is possible for a user to be >> authorized to view data in a number of databases... rare, but possible) >> >> I don't know if there is a better way to do this, but this is the way I have >> come up to achieve this end. The key (as others here have mentioned) is to >> be very careful about how you use editing contexts. I explicitly create the >> Object Store Coordinators for the session and then use those to manage >> session specific database connections. >> >> Create the Object Store coordinator in the Session() constructor >> >> emrOSC = new EOObjectStoreCoordinator(); >> emrEC = ERXEC.newEditingContext(emrOSC); >> >> >> >> When someone changes their current facility, I check authorization then >> check to see if I need to change the database and if I do, I dump the old >> OSC, recreate it and connect: >> >> ERXEOAccessUtilities.closeDatabaseConnections(emrOSC); >> emrOSC.dispose(); >> emrOSC = new EOObjectStoreCoordinator(); >> emrEC = ERXEC.newEditingContext(emrOSC); >> EOUtilities.connectWithModelNamed(emrEC, COMMON_MODEL_NAME, >> null); >> EOUtilities.connectWithModelNamed(emrEC, EMR_MODEL_NAME, cdict); >> emrEC.setFetchTimestamp(System.currentTimeMillis()); >> >> >> Notice, I only want to override the database connection for the EMR Model so >> all the others are reconnecting to the same (common) database. (By the way, >> thanks to whoever wrote ERXEOAccessUtilities.closeDatabaseConnections >> because it saves an awful lot of legwork iterating through channels and >> contexts and such) >> >> I'm pretty sure that I'm missing an awful lot of optimization that you get >> when you take advantage of the way EO generally uses object store >> coordinators, cooperating object stores and snapshots, but so far, that >> hasn't been a problem. I tend to be a bit harsh in invalidating objects so >> that I don't get into trouble with parts of the object graph that may be >> hanging around due to my own carelessness so I'm moderately confident that >> if more optimization becomes necessary, I can take advantage of more of the >> EOF goodness. >> >> One good thing is that doing this really forces you do follow the editing >> context best practices that have been talked about here and on the wiki >> (don't use default ec, using localInstanceOf, use ERXEC...) >> >> I'm always looking for better, more elegant ways to do this so any ideas or >> patterns or suggestions are welcome. >> >> >> >> Larry Mills-Gahl >> [email protected] >> >> >> >> On Jun 18, 2012, at 12:32 PM, Paul Dunkler wrote: >> >>> Hi List, >>> >>> is there any way to have different database connections per session? I need >>> this in an application for giving the user the ability to change between >>> several different copies of the database to work on. >>> >>> I always tried to copy EOModels and so on, read some mails from the list >>> but not really found an answer for that problem. I know that what i trying >>> to do will cause a bit memory overhead but i do not want to provide ~25 >>> applications just because they need different database connections. >>> >>> Would be nice to get some suggestions... >>> >>> -- >>> With best regards >>> Paul Dunkler >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/lmg%40webfarm.com >>> >>> This email sent to [email protected] >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > > This email sent to [email protected] -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/gvc/practical_webobjects _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
