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@hidden> 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.
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)
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|