Let me be more clear. It is possible to run migrations automatically but the different databases (whose connection dictionary is only known inside a session) will not all be automatically updated.
I have migrations turned on and automatically connecting to (and updating) an empty database that is the same structure as all the session specific databases. Right now, the management of the per-session database schemas is a combination of perl and groovy. This works pretty well (if sort of inelegantly) I do have a partially completed feature that will give me more consistent manageability. The feature is intended to allow web administration of new databases (create a new database on one of the available servers, run migrations, profit). This will necessarily require more control over migrations so although I am concerned about completely automatic migrations in this situation, with the right balance of feedback and control (and good backups) I'm going to release this to the client configuration folks so they can turn up a client environment more easily. Larry Mills-Gahl [email protected] On Jun 18, 2012, at 5:04 PM, Larry Mills-Gahl wrote: > Not automatically. Migrations happen during the application startup and at > that point, they have default connection dictionary information. I do use > migrations but that just migrates the common databases and an empty stub > database (that uses the default connection dictionary) on the main db > server. Using that empty stub means that I don't have to worry about loading > and unloading different model groups. If you aren't connected to a particular > facility db, you are connected to the stub and EO is happy about all the > objects, you just don't have any data. > > I have some old perl that will iterate through the active databases to check > schema consistency. > > When I have extra time (come on ... stop laughing!!) finishing the utility to > trigger migrations across active databases is on the list of things to do. > Right now it's not an urgent or consistent issue so it doesn't get top > priority.I haven't made this completely automatic (because I'm chicken and > have an allergy to injecting lead into my own foot) > > Larry Mills-Gahl > [email protected] > > > > On Jun 18, 2012, at 4:47 PM, Chuck Hill wrote: > >> 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/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/archive%40mail-archive.com This email sent to [email protected]
