Re: difficulties with cross-model relationship
Re: difficulties with cross-model relationship
- Subject: Re: difficulties with cross-model relationship
- From: TW <email@hidden>
- Date: Fri, 20 Mar 2009 16:41:09 -0700
On Mar 20, 2009, at 4:15 PM, Chuck Hill wrote:
On Mar 20, 2009, at 3:59 PM, TW wrote:
What you are writing does not seem to be consistent. If you
"added the existing framework to the new framework" then it does
not make sense to expect "the older framework to retain
visibility to the types in the newer one". The new can see the
existing, not vice versa. Maybe if you describe the problem in
specifics with the real names that may help to clarify things.
I think that's exactly right. I think I had an expectation that
wasn't reasonable. :-) The real problem is a can of worms. I work
for a professional school at UCLA - a campus whose technology is
highly decentralized. So, one model represents Employee data
(what I was calling 'B') that I pull from central campus daily.
Locally, here in our school, we also have an ldap directory,
completely separate from anything central campus holds. It is
specific to our school only. These data sources are both modeled
and have their own frameworks. I have married them
programmatically with manual fetches (LDAPPerson <-> Employee)
for login to my most important app - a timesheet app. This all
works great but is highly inflexible for new apps - which brings
me to where I am. My latest app is for faculty to login only.
Believe it or not, the campus Employee data does not have any
fields that specify the "type" of user. But our local ldap
directory does. That's problem one.
The faculty project is about their "Papers." So, I wanted to
relate Papers <<->> Employee. A Paper could have multiple faculty
contributors and a faculty person could have multiple papers.
Also, I wanted a new model (same database) for this faculty
project because it doesn't need to know about timesheet stuff.
So, I built that model (what I was calling 'A') and I was trying
to build a relationship to the Employee data in 'B'. Since the
many to many requires the Employee entity to maintain pointers
back, it isn't working. But the truth is, for this project I'm
only interested in faculty - something Employee doesn't even know
about.
can of worms.
I think I have a problem with approach. I think the best
approach may be to sub-class my user types in a third
framework? I've been putting this off. :-)
I am really not sure what you are doing and what you are seeing
so it is hard to advise you on the best direction to take.
I understand why the approach I was taking won't work. So, maybe
you can vet the one I'm trying today. I was thinking I need to
create a framework to relate LDAPPerson and Employee in a single
framework and create new model there with GenericUser. This
GenericUser would then wrap both their ldap source and their
employee data source in a single entity and hold that
relationship. It sounds like a lot of overhead but maybe the
right thing to do. Then I could subclass that user into
FacultyPerson, StaffPerson, StudentPerson, etc. , maybe even in
separate frameworks. This sounds like it could put me in a better
position to achieve what I want.
I think that is exactly the right thing to do: create an object to
wrap and hide the complexity of the ldap source and the employee
data source.
Chuck
Thanks Chuck. I've made some progress on this today. One place I'm
apparently getting stuck is putting valid qualifiers in my model
for my inheritance structure. I've got a new abstract entity
LDAPEmployee which inherits from InetOrgPerson (from my ldap
schema). I added a relationship "employee" between this entity and
my Employee entity in my employee source using the the common
employeeNumber. So far so good. However, I want to put a qualifier
on LDAPEmployee that requires an Employee entity to exist. My hope
is to be able to ask for LDAPEmployee objects and only get
ldapusers where there's also a related Employee.
EOF does not support that.
Crossing databases = hard. I get it.
So, I created a restricting qualifier in Entity Modeler that looks
like:
employee!=null
That qualifier can only refer to attributes of the object (cols in
the table).
I get an error that there's a failure to parse my qualifier. Is
this because the syntax is bad or because I can't create a
qualifier like this? I've looked everywhere for definitive
information about what is valid for these qualifiers and there's
very little info out there.
Can't do it like that. You could add a method employees() to
LDAPEmployee that did a qualified fetch perhaps.
Hmm, seems like it becomes less and less useful to model it. Without
any restricting qualifier I can't have LDAPEmployee at all - since a
restricting qualifier is necessary. I could just model FacultyUser,
StaffUser, etc. to inherit directly from InetOrgPerson and put the
appropriate restricting qualifiers on "employeeType" but those are
both of the type EmployeeUser. I really want to have that super class
in there. Is there a way to accomplish this that I'm not grokking?
Tim
UCLA GSE&IS
_______________________________________________
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