As a workaround for this situation I am removing the relationship from the model and just using a setReferrer(AppUser) and referrer() in Referral. It's a bit of a brute force method, but it is behaving as expected in the app and some tests of walking the object graph in different directions. This doesn't require any changes to the database(s) and only minimal changes to the model, so this allows me to roll this out while I make whatever sacrifices to the gods (and the list) that are required to track this down.
Thanks for your help,
Larry
On May 7, 2012, at 4:06 PM, Chuck Hill wrote: Hi Larry, On 2012-05-06, at 1:17 PM, Larry Mills-Gahl wrote: I am having a model problem with a cross-model, cross-database (and apparently crossed-streams) situation.
A "Referral" object is a subclass of AbstractEncounter (subclassed in separate tables for each entity).
The "referrer" relationship is only part of the Referral object, not any superclass.
The "referrer" relationship is to an object that is a subclass of AppUser (vertical inheritance with qualifer of persontype = some int flag)
VI is seldom used, so you may be hitting a VI specific bug.
I was wondering if there was something about the model that was either not being modeled properly or was asking the eo environment to do some gymnastics that it doesn't like.
Nothing terribly exotic about that, and I can traverse the relationship when I am creating the Referral (I can set the relationship and display the properties of the AppUser subclass (name, etc...)
The problem arises when I try display a list all the objects that are subclasses of AbstractEncounter.
I can display all of the other encounter classes, but when I try to access a Referral, I get the following error:
java.lang.IllegalStateException: The object with globalID _EOIntegralKeyGlobalID[AppUser (java.lang.Integer)1044] could not be found in the database. This could be result of a referential integrity problem with the database. An empty fault could not be created because the object's class could not be determined (e.g. the GID is temporary or it is for an abstract entity).
What is the full stack trace for that exception? What SQL is executed just before that? The object does exist (with primary key 1044) and a valid persontype. If I remove the relationship from the model and call objectWithPrimaryKey for the object, I can see it, so it looks like the object is intact, but somewhere along the relationship, the Referral apparently can't tell that the user is a ClinicUser and not just an abstract AppUser (those abstract users are such slackers and never get anything done)
It would be interesting to know how it is fetching for it. Are Referral and ClinicUser in different databases? If so, I wonder if it is trying to find it in the wrong EODatabase.
I think this might be key to finding out what is going on although checking the editing contexts and object store coordinators just before the calls shows that they are all set as expected. Referral and AppUser are indeed in different databases I suspect that along with the vertical inheritance model are part of the problem.
The other complicating issue is that I'm working with two editing contexts (to object store coordinators) One OSC is used for data that is retrieved from one database for an entire session (actually for all sessions ... things like configuration, authentication, preferences, etc...). The other editing context is changed to connect to a separate database for one of the models in the group based on the current facility being viewed.
I don't know how that would affect just this relationship because I'm pretty careful about using localInstanceOf to start the graph and since the referral is retrieved from the correct editingContext, the relationship "referrer" should also use that editingContext and object store coordinator... right?
Yes, I would expect that to just work. I have not been able to figure out why the Referral is getting an abstract entity (because I know the GID is not temporary... hmmm... should the primary key also include the persontype?)
It needs to find the row to determine the exact entity. Because no fetch is returning a row, all it has to use is the abstract entity. I expect that is a symptom, not the problem. I will hazard a guess that EOF is making a bad join and failing to fetch the data.
|