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.


> 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.


> 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.


> Any help in tracking this down would be greatly appreciated. I have to roll 
> out a workaround this evening and would very much like to get back to the 
> cleaner model-based setup so I don't add too much crap that needs to be 
> cleaned out later.



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/gvc/practical_webobjects








Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to