Hi Dave,
On 26/04/2007, at 11:33 AM, Dave Elsner wrote:
I have an WO5.3 application I want to deploy to five different clients, all have the same DB (Oracle) schema but different data. I would like to use a shared database with a new column in each table "client" that has the client ID. Then override awakeFromInsertion for all EOEntities to set the client ID
That's what I've done (though it's done generically in a super class rather than per entity). Something like:
public void awakeFromInsertion( EOEditingContext ec ) {
super.awakeFromInsertion( ec );
if ( ec instanceof MyEditingContext && hasKey( CLIENT_KEY ) ) {
Client currentClient = ( Client )ec.valueForKey( CLIENT_KEY );
if ( hasReverseRelationship )
addObjectToBothSidesOfRelationshipWithKey( currentClient, CLIENT_KEY );
else
takeValueForKey( currentClient, CLIENT_KEY );
}
}
and also add to the Application constructor a loop that sets an EOQualifier on each entity in the model limiting objects to the current client.
Sure that's one way to do it if you're going to be running them as separate instances. I'm dealing with this within the same instance(s) by an additional table ClientDomain (Client <-->> ClientDomain). I've got some cover methods in my Application class that when needed can find the relevant object for a request. It stores the result in the userInfo dictionary of the request so that this only need be fetched once, if at all - seeing as these objects are pre-fetched in a shared ec.
public Client clientForRequest( WORequest aRequest ) throws EOObjectNotAvailableException, EOUtilities.MoreThanOneException;
public ClientDomain clientDomainForRequest( WORequest aRequest ) throws EOObjectNotAvailableException;
I'm then (in a base controller/component) able to have cover methods for these. e.g.,
public Client myClient() {
return myApplication().clientForRequest( context() );
}
and whenever I need to create data, I create an instance of my subclass of EOEditingContext which is instantiated with an additional parameter for the ClientDomain, allowing it to localise as necessary internally and for the above valueForKey to return the related Client object.
Questions:
* Is this the correct approach to solve this problem? (i.e not wanting to update X number of identical DB schemas every-time a change is made, keeping the data in the one location for reporting)
Perhaps the above helps.
* I tried EOEntity.setRestrictingQualifier but that overrides any single table inheritance setup in the model. Is there away to merge two EOQualifiers?
When iterating through each entity, do an EOAndQualifier with any existing restricting qualifier so that you don't blow it away.
with regards,
--
Lachlan Deck