• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: object's class could not be determined
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: object's class could not be determined


  • Subject: Re: object's class could not be determined
  • From: Lachlan Deck <email@hidden>
  • Date: Tue, 08 May 2012 14:28:51 +1000

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@hidden


 _______________________________________________
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

  • Follow-Ups:
    • Re: object's class could not be determined
      • From: Larry Mills-Gahl <email@hidden>
References: 
 >object's class could not be determined (From: Larry Mills-Gahl <email@hidden>)

  • Prev by Date: Re: Reminder: 7 days left for WOWODC early bird pricing!
  • Next by Date: Re: build path entries missing
  • Previous by thread: object's class could not be determined
  • Next by thread: Re: object's class could not be determined
  • Index(es):
    • Date
    • Thread