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 13:56:02 -0700
On Mar 20, 2009, at 12:42 PM, TW wrote:
On Mar 20, 2009, at 11:58 AM, Chuck Hill wrote:
On Mar 20, 2009, at 11:49 AM, TW wrote:
On Mar 20, 2009, at 7:31 AM, Chuck Hill wrote:
On Mar 19, 2009, at 11:38 PM, TW wrote:
All:
I have an entity called "Paper" in a new model A that I would
like to relate to an entity "Employee" in an established model
B. Each of them are in their own framework project but both
models use the same database. I was hoping to make this a many
to many and flatten it. I've tried many things tonight to get
this to work but apparently I'm doing all the wrong things.
Apple's documentation seems to indicate that I should be able to
resolve type references to any models included in the model
group. I've added B eomodel to the model group section in my
EOGenerate file.
I've tried adding B.framework the build path of A.framework.
This seems to do the right things and add the join table, etc.,
but then model B can't resolve type references to the entity in
model A. I'm assuming I'm just really confused about how this
should work but I've reached my limit for banging my head
against it.
I'd be really grateful if anyone doing something similar could
share how they may have gotten this working.
It sounds like you have a circular dependancy: Framework A
depends on Framework B _and_ Framework B depends on Framework A.
That just won't work in Java. I think you can only do this if
the relationships are only in one direction or if both models are
in the same project.
Chuck
Thanks Chuck. I actually did avoid that happening since I've only
added the existing framework to the new framework (and not the
reverse). The problem I see on my end is that everything seems to
work - relationship add, flattening, etc., but then when I clean
everything the older framework does not retain visibility to the
types in the newer one.
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
--
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