Re: difficulties with cross-model relationship
Re: difficulties with cross-model relationship
- Subject: Re: difficulties with cross-model relationship
- From: Chuck Hill <email@hidden>
- Date: Fri, 20 Mar 2009 16:15:12 -0700
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.
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.
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