Re: modeling problem
Re: modeling problem
- Subject: Re: modeling problem
- From: TW <email@hidden>
- Date: Tue, 31 Mar 2009 14:33:12 -0700
On Mar 31, 2009, at 10:06 AM, Chuck Hill wrote:
On Mar 30, 2009, at 4:29 PM, TW wrote:
My goal was to have an entity/class (where InetOrgPerson is
super) in a "middle" framework that can be used to wrap a
relationship between ldap user and database employee (each
modeled in their own frameworks). So, the way I have it set up
there's really no difference between InetOrgPerson and
GenericUser except that GenericUser has the relationship to
<database employee> and InetOrgPerson does not.
I still wonder if GenericUser should have a relationship to both
InetOrgPerson and DatabaseEmployee.
With that approach, it sounds like GenericUser would have to have
it's own data table separate from the other two?
Doesn't it need to anyway for the relationship to DatabaseEmployee?
Not really. Time for ascii sheep. This is what I have.
LDAPModel ---to build path--> UserModel <--to build path----
DBModel
======== ========= ================
InetOrgPerson GenericUser <-------------> Employee
(InetOrgPerson/parent)
The only relationship (on the right) uses "employee_id."
That is in the LDAP information?
Yes, InetOrgPerson has "employeeNumber." We use FileMaker-based tools
I created for adding accounts to OD. They call DSImport to add records
to OD as needed and they're set up to push the employee_id into that
attribute.
Actually, there's a scenario right there that supports your suggestion
to have an intermediary GenericUser table since that is essentially
the same position the old FileMaker database holds - collection of
"everyone."
This approach makes the ldap side of things the starting point
since that is the store that knows what type of user the person is.
If ldap authentication is successful, I query for the matching
GenericUser which is essentially an ldap person since GenericUser
inherits from InetOrgPerson.
That sounds like a correct use of inheritance. I think you are
going to need a restricting qualifier on InetOrgPerson that is
always false.
I tried the (1=0) restricting qualifier and EOGenerator did not like
it and coughed up an error about being unable to parse the qualifier.
Good thought though.
Well, I've got a version in my repository the way it is. I'm trying to
model it the other way around now and we'll see how that works.
Then, I can test for the related employee record. If there, foo, if
not, bar - depends on the app.
It sounds like your preferred approach would be to create another
table for GenericUser making it a database entity instead of
inheriting from InetOrgPerson. That could work too. The problem
there is then I have two entities, InetOrgPerson and GenericUser
that have to have similar attributes, including "usertype,"
"email," etc. And, when a new Employee is created, I'd have to
force the creation of a GenericUser.
It sounds like you are on the right track. I think.
I can see advantages each way and it's too bad I'm somewhat at the
mercy of the greater campus.
Hence the lure of herding goats and sheep, living on wine and cheese.
Chuck
_______________________________________________
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