Re: Using database objects in different schemas
Re: Using database objects in different schemas
- Subject: Re: Using database objects in different schemas
- From: Jean-François Veillette <email@hidden>
- Date: Tue, 12 Dec 2017 10:49:02 -0500
You might need to create a new jdbc connection for every user.
If I understand your situation correctly, I would try to use a unique EOF stack
for every session (user). In practice this can work well as long as you don’t
have too many sessions (exhausting DB connection).
You will have to change the ‘delegate’ that updates the connection dictionary
so that it updates it specifically for the current user.
This might sound more complicated than it really is, here is the 2 things you
have to do (in short):
1- make sure you create a new EOF stack for every user:
2- Make sure the connection dictionary is correctly set for every new stack
Now in Detail:
1- make sure you create a new EOF stack for every user:
I would user the pattern of a ‘Provider' to assist me in doing so:
- create an editing context provider that will be responsible for
giving you EOEditingContext instances (let’s name it: ECProvider)
- have provider to require arguments like the current user’s id, or
whatever you need to be able to set the correct connection dictionary.
- give editing context from a new EOObjectStoreCoordinator
(new/specific EOF stack).
2- Make sure the connection dictionary is correctly set for every new stack
Improve with the provider created in step 1
- the new stack will trigger the initialization of the database
connection dictionary (by way of NSNotification), the object responding to that
notification should be able to adjust the connection dictionary according to
the ‘current user’. You want to update the connection dictionary here, as part
of the notification dispatch.
ps: Set a breakpoint on
‘ERXModelGroup.resetConnectionDictionaryInModel’ to better understand the
mechanism (this is the default method that will update the database connection
dictionary when a model is loaded in memory).
ps: you can add yourself to receive such notification by “
NSNotificationCenter.defaultCenter().addObserver(this, aSelector,
EOModelGroup.ModelAddedNotification, null);” Note that If many objects receive
notification, the order is not predictable, so only one should be responsible
for updating the connection dictionary.
ps: keep a cache of existing connection based on those users to avoid opening
too many connections to the DB as this will most likely be a problem.
ps: find a way to close those connections when they are no longer needed (when
session dies)
Every time you need a new EOEditingContext, ask ECProvider for it.
If you use session default EC, set it from this provider, just so that you can
simply use session.defaultEditingContext later.
I’ve never done this, but this is what I would try to achieve it.
Hope this help,
jfv
> On Dec 12, 2017, at 5:59 AM, André Rothe <email@hidden> wrote:
>
> Hi,
>
> I use an Oracle database, which has a "master" schema/account. This aacount
> uses my Webobjects application. There are a lot of "slave" schemas/accounts,
> which grant privileges on their own objects (tables, views etc.) to the
> master. So the master can access these objects like:
>
> select * from slave1.table1;
> select * from slave2.table1;
>
> The objects within the "slave" accounts are identical, so it could be
> possible to use one EO model for all slaves.
>
> How can I access these objects, if the master don't know the user/password
> for every slave? I cannot change the credentials for the model within the
> application without the passwords, but I have to change the source of each
> object within a model to the specific slave before I execute any query. Or
> should I use rawSQL?
>
> I have no idea, how I could solve this with WebObjects. Is it possible at all?
>
> Best regards
> André
>
> _______________________________________________
> 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
_______________________________________________
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