I agree, cross model relationships with different database connections shouldn't be used in real applications : eof bugs aside, there's one major problem : it's not transactionnal. Larry setup is interesting though, looks like the new old wo 4.5.1 :), the optimistic locking will work for sure !
Alex 2012/6/19 Mike Gargano <[email protected]> > those are definitely all problems i am currently facing. it's fine if > everything is sequestered off into it own model, but relationships between > them are not going to happen unless you manually manage what relationship's > object gets pulled into what context. it's not manageable for any > real-world system. > > Sent from my iPhone > > On Jun 18, 2012, at 5:31 PM, Ramsey Gurley <[email protected]> > wrote: > > Speaking of which, I wonder what migrations do for cross db fks? Does it > blow up trying to form a constraint? I'll have to look sometime. > > Which raises another interesting issue. Do you create cross model > relationships Larry? I could see that causing problems. For example, create > an EO in common with an FK to an EO in emr. Then change connections! Now > the common EO's relationship points off into space, or worse, at some other > object. > > Maybe that could be mitigated by forming to-one's using a two key join > table in the destination entity's DB with a unique index on one key column? > Interesting problem in any case. > > Ramsey > > On Jun 18, 2012, at 2: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/mgargano%40me.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/alexis.tual%40gmail.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]
