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/archive%40mail-archive.com This email sent to [email protected]
