Yes.
If the tables do have a primary key, then you can make them in to EOs. If you want to create new objects, you will have to ensure that the PK value is populated in your code – clearly EOF can’t make this value for you.
Q2. There is what I would consider a location attribute, but instead of making it an attribute, it is used as a database name.
That is pretty common for a multi-tennant system. I am not saying it is good, just common. ;-)
So there is one model, but several databases, all similar except for the connection dictionary. The dictionaries only differ slightly:
jdbc:postgresql://localhost:5432/locationA
<< (At least postgres is involved.)
VS
jdbc:postgresql://localhost:5432/locationB
EnterpriseObjects.pdf discusses:
How does an EOObjectStoreCoordinator determine which of its EOCooperatingObjectStores should service a particular fetch specification? Remember that within an EOModelGroup, entity names must be unique. Also remember that fetch specifications are entity-centric—every
fetch specification is specified on the basis of a particular entity. So an object store coordinator simply looks for the list of entities registered within its cooperating object stores to match an entity name to particular cooperating object store.
So I need to setup a EOObjectStoreCoordinator (OSC) for each different database, and change the connection dictionary so it has the correct jdbc url:
Or you could use a different app instance for each location and set the connection info in JavaMonitor or an additional properties file.
jdbc:postgresql://localhost:5432/locationA << default with model
jdbc:postgresql://localhost:5432/locationB
jdbc:postgresql://localhost:5432/locationC
On these OSCs, I can use EODatabaseContext.forceConnectionWithModel to set the correct connection dictionary, or EOUtilities.connectWithModelNamed, or some other method somebody (not me) knows of. Then I just use ECs from the correct OSC to do the raw
row non-EO fun:
EOObjectStoreCoordinator locationBObjectStore = new EOObjectStoreCoordinator();
EOEditingContext editingContextLocationB = new EOEditingContext(locationBObjectStore);
Does this sound like the correct direction to deal with these databases?
Yes.
refs:
Re: Different Database Connection per session for the same model
site:lists.apple.com goat herding
What could go wrong?
Grin.
Thanks,
Greg Brown
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription: