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 15:59:17 -0700
On Mar 20, 2009, at 1:56 PM, Chuck Hill wrote:
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
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.
So, I created a restricting qualifier in Entity Modeler that looks like:
employee!=null
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.
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