Re: Multiple clients in single DB
Re: Multiple clients in single DB
- Subject: Re: Multiple clients in single DB
- From: Ken Anderson <email@hidden>
- Date: Fri, 27 Apr 2007 06:52:25 -0400
I have had similar issues with those flattened join tables, so I
always make them a real entity so that I can control how things
work. It's also useful in the event you decide that the join itself
requires a new attribute.
On Apr 27, 2007, at 1:35 AM, Dave Elsner wrote:
I spoke to soon, it seems that awakeFromInsertion does NOT
register flattened tables being inserted?
I guess I really don't need to store the client for a Flatteren
join table as it can be determined via the relationships. However
it seems odd awakeFromInsertion does not get called even though
there is a "insert" being sent to the DB.
Is there away to know when a flattened table is being inserted?
I have tried both awakeFromInsertion and Chucks
CooperatingEditingContext.objectsToBeInserted() but neither work.
Dave
On 27/04/2007, at 10:47 AM, Dave Elsner wrote:
Excellent, that was the confirmation I was looking for. For now it
works for multiple application instances but eventually I will run
all clients from the single instance. Thanks.
On 27/04/2007, at 6:35 AM, Lachlan Deck wrote:
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40uow.edu.au
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com
This email sent to email@hidden
_______________________________________________
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