• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: modeling problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: modeling problem


  • Subject: Re: modeling problem
  • From: Chuck Hill <email@hidden>
  • Date: Tue, 31 Mar 2009 10:06:25 -0700


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?


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.



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



--
Chuck Hill             Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects







_______________________________________________ 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
  • Follow-Ups:
    • Re: modeling problem
      • From: TW <email@hidden>
References: 
 >Re: modeling problem (From: TW <email@hidden>)

  • Prev by Date: Re: How does concurrency control work in WO?
  • Next by Date: Re: Displaying Local Time on a Web Client
  • Previous by thread: Re: modeling problem
  • Next by thread: Re: modeling problem
  • Index(es):
    • Date
    • Thread