Re: Auto-filtering EOF queries based on the current client
Re: Auto-filtering EOF queries based on the current client
- Subject: Re: Auto-filtering EOF queries based on the current client
- From: Ken Anderson <email@hidden>
- Date: Tue, 4 Sep 2007 14:17:46 -0400
Sam,
I do exactly that - subclass EOEditingContext and append an
additional qualifier. In addition, I use userInfo on each entity to
define what the keypath is to the owner. In the userinfo of
entities, I have things like:
OwnerKeyPath owner
or
OwnerKeyPath order.owner
In my EC subclass, if the entity being queried has a userInfo entry
'OwnerKeyPath', I then add that qualifier. It keeps things nice and
generic, and fetches of contained data can always link back to the
proper owner.
Ken
On Sep 4, 2007, at 2:08 PM, Sam Barnum wrote:
I'm designing a WO app where multiple clients maintain their own
discreet sets of data. However, I'd like to keep everything in a
single database.
Certain entities are "global", meaning shared among all clients. A
good example would be a table containing status names for jobs.
This is the same for all clients.
Other entities are "compartmentalized", meaning once a user from
client A logs in, he can only fetch records which are linked to
client A (never from client B). A good example would be the
"project" entity.
Now the tricky part. I'd like to automate this filtering, so I
don't have to explicitly qualify "client=A" for every fetch against
Projects I do. Ideally, a user can use a D2W interface to do a
search for projects beginning with "P", and it will only return
results for his client.
My plan is to subclass EOEditingContext, and have it apply a custom
qualifier to any fetch against a "compartmentalized" entity. I'm
already using a subclass of EOEditingContext which keeps a
reference to the logged in user, for setting "modified by" flags
automatically. Almost all EOF activity uses this custom subclass
already.
Before I implement this, I was wondering if anyone else has any
suggestions on how to implement this, or an alternate approach, or
dire words of warning. I don't think I'm breaking any EOF
commandments here, but it still feels pretty invasive.
Thanks, all!
_______________________________________________
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