For the moment, I'm handling the relationships manually (mimicking the methods
that EO usually uses for the relationships so that the code should work
similarly, but the relationships are just not part of the model). This seems to
be working at the moment and it will give me time to reexamine the model and
some of the underlying bits to see which direction I can run and how far (I'm
not so fast as I used to be ... come to think of it, when I was faster, I
didn't know which direction to run so I kept running into bugs there too)
Well, thanks for help on direction to run... I appreciate it.
Larry
On May 7, 2012, at 6:28 PM, Lachlan Deck wrote:
> On 08/05/2012, at 12:06 PM, Chuck Hill wrote:
>
>> 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 seem to recall that scenario being a problem which (IIRC) is in the
> database context and EOEntity (when determining relationships/operations) and
> related classes. Some private methods need overriding.
>
> I overrode the DB context to work around it (partially) but may have also
> done so in the entity itself -- to fetch from a particular direction.
>
> Are you using Wonder? WO5.4.x has a bug in EOEntity which I fixed in Wonder
> for inheritance.
>
> // IIRC the problem is here in EODatabaseContext
> private void createAdaptorOperationsForDatabaseOperationAttributes(
> EODatabaseOperation dbOp, NSArray atts )
> {
> EOEntity entity = dbOp.entity();
> switch ( dbOp.databaseOperator() )
> {
> <...>
> case 2: // bug
> {
> // this will create locking operation
> // if partial entity has no changed values!
> if ( changedValuesCount == 0 || blobsCount > 0)
> {
> <...>
> }
> }
> }
>
> ---------------
> Here's the comment I've got in my code from 2007.
>
> // FIXME: (lachlan) we do not want a locking operation when
> changedValuesCount == 0.
> // I don't even know if we want one for blobsCount > 0.
> // Bug report submitted to radar.apple.com (id 5632577)
> //if ( changedValuesCount == 0 || blobsCount > 0 )
> if ( blobsCount > 0 )
>
>
> Run away if you can :-)
>
> Lachlan Deck
> [email protected]
>
>
_______________________________________________
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]
