Hi Greg,

On 2/24/2014, 5:10 AM, "Greg Brown" wrote:

I have a given database I want to integrate into some existing webobjects info 
systems.

The database is not too normal, so some directions to proceede would be 
appreciated.

“not too normal”  LOL!



Q1. Some tables have no primary key, so no EOs. But  there is a method called 
rawRowsForSQL on the EOUtilities class. Is that the best option other than raw 
sql?

Yes.


All other tables have non-numeric primary keys , columns which really should be 
entity attributes and not primary keys. Wonder has 
er.extensions.eof.ERXEOAccessUtilities; any other things I should look at for 
raw row non-EO fun? raw SQL?

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.

Chuck



Thanks,

Greg Brown
[email protected]<mailto:[email protected]>




_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      
([email protected]<mailto:[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]<mailto:[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]

Reply via email to