• 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: Problem with objectsWithFetchSpecification
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with objectsWithFetchSpecification


  • Subject: Re: Problem with objectsWithFetchSpecification
  • From: Ian Joyner <email@hidden>
  • Date: Fri, 9 Sep 2005 14:55:48 +1000

Now here is something weird. In EOModeler, I change the Class Name and the Client-Side Class Name back to EOGenericRecord and this causes the records to load OK:

[2005-09-09 14:49:34 EST] <AWT-EventQueue-0> CronusIII.client.AssetInterfaceController.load_test_tree ao9 ()
[2005-09-09 14:49:34 EST] <AWT-EventQueue-0> CronusIII.client.AssetInterfaceController.load_test_tree tt 42
apple.awt.EventQueueExceptionHandler Caught Throwable : java.lang.ClassCastException
java.lang.ClassCastException
at CronusIII.client.AssetInterfaceController.load_test_tree (AssetInterfaceController.java:778)


As you can see, it can't cast EOGenericRecord to Skills_test so causes one of the afore-complained-about ClassCastExceptions. So seems something strange with what EOGenerator has generated or something around that area. At least I have something a little more positive to work from.

I'll try your other suggestions now (although clean builds and entire rebuild of DB has been done several times :-))

Thanks
Ian

On 09/09/2005, at 2:00 PM, Chuck Hill wrote:

Hi Ian,

On Sep 8, 2005, at 5:07 PM, Ian Joyner wrote:


Thanks Chuck and Sacha. It is completely horizontal table mapping, so restricting qualifiers are not needed (according to p 105 of Using EOModeler).


Yes, they are not needed. I was just wondering if you had left them in from some past experiment and they were causing trouble.



On 09/09/2005, at 3:39 AM, Chuck Hill wrote:

On Sep 8, 2005, at 12:21 AM, Ian Joyner wrote:

I'm having a strange problem fetching from tables using horizontal inheritance. I have a hierarchy with Skills_test at the root and subclasses Graded_test and Value_test. Doing a fetch on Skills_test, I expect all records in Graded_test and Value_test to be returned. I see the SQL on the server side and the report "9 row(s) processed, but get nothing on the server side:

NSArray /*[Skills_test]*/ tests = editingContext ().objectsWithFetchSpecification (new EOFetchSpecification ("Skills_test", null, null));

System.out.println (".load_test_tree tt " + tests.count ());

Suspecting deep fetching,



It should be deep by default.


Yes it was, I even printed out isDeep on the FS which showed true.


Sanity check: are there any PK values duplicated between the Graded_test and Value_test tables?



There were (shouldn't they be getting separate PKs anyway). So I reloaded the Value_test table with distinct PKs, but still it doesn't work.



No, they should not be getting separate keys. They should be getting keys as if all rows were in the abstract base class. The key is all EOF has to differentiate the subclasses after they are fetches. Take a look at an EOGlobalID. All it will show is the abstract base entity name and the PK. EOF registers a class description (think that is the right way to say it) against each globalID when they are fetched. If you duplicate PKs, EOF won't be able to tell one from the other.




Tool Curiosity: What is /*[Skills_test]*/ for. Looks like you are using some sort of tool.


No such luck. I just document what is expected to be in the array this way so if something weird comes out of it causing a ClassCastException you can double check. Of course with generic arrays, you don't have to put casts all over the place and never get ClassCastExceptions.



Ah well, back to dreaming. :-)



I changed this to just fetch on Graded_test:

NSArray /*[Skills_test]*/ tests = editingContext ().objectsWithFetchSpecification (new EOFetchSpecification ("Graded_test", null, null));

System.out.println (".load_test_tree tt " + tests.count ());

again seeing that fetches are made to the database, but nothing actually returned.

I then changed the fetch spec to retrieve any other table in the database and I get the correct number of rows returned, so it seems to be something weird with the Skills_test hierarchy. Can anyone give a clue as to why this code is returning records from every other table in the database except the ones I want? I'm sure it's something strange in the model (parents are set correctly, abstract is only on for Skills_test), but have not been able to pinpoint what the problem is.


That is a hard one. Have you specified restricting qualifiers on the entity in the EOModel that do not match what is in the DB? I can't think of anything else. I'll ruminate on it for a while.



There are no qualifiers. Since all subclasses only share the attributes name, number, and description, and all the other attributes are completely different, I'm using horizontal mapping. I'm sure I've just missed something really stupid, but it looks like it's a rebuild the model problem testing every step along the way until I find out.



I'm afraid you are correct. Something is very, very wrong but I can't put my finger on what it would be. It is as if EOF can't locate an entity for the rows it is fetching or is locating the wrong entity and thus rejecting what it has fetched.



The server side definitely loads the tables:

[2005-09-09 09:54:11 EST] <WorkerThread7> evaluateExpression: <com.webobjects.jdbcadaptor.OpenBasePlugIn$OpenBaseExpression: "SELECT t0.GRADE_SET_KEY, t0.PARENT_TEST_KEY, t0.PRIMARY_KEY, t0.TEST_DESCRIPTION, t0.TEST_NAME, t0.TEST_NUMBER FROM GRADED_TEST t0">
[2005-09-09 09:54:11 EST] <WorkerThread7> 33 row(s) processed


[2005-09-09 09:54:11 EST] <WorkerThread7> evaluateExpression: <com.webobjects.jdbcadaptor.OpenBasePlugIn$OpenBaseExpression: "SELECT t0.BEST_SCORE, t0.LOWER_IS_BETTER, t0.PARENT_TEST_KEY, t0.PRIMARY_KEY, t0.TEST_DESCRIPTION, t0.TEST_NAME, t0.TEST_NUMBER FROM VALUE_TEST t0">
[2005-09-09 09:54:11 EST] <WorkerThread7> 9 row(s) processed


but the output on the client side is:

[2005-09-09 09:54:11 EST] <AWT-EventQueue-0> .load_test_tree ao1 ()
[2005-09-09 09:54:11 EST] <AWT-EventQueue-0> .load_test_tree tt 0


A couple of things to try before you rebuild the model:

1. Add an omniscient observer (see NSNotificationCenter) and see what notifications are flying around when these rows are fetched
2. Try and do the fetch on the server in Java (the above just shows the SQL not what happens immediately after). Can the server app fetch OK but not the client app?
3. If you have not already done this 5,000 times, quit Xcode andEOModeler, delete the build/ directories under the projects, start Xcode and do a full build.



Chuck


--
Practical WebObjects - a book for intermediate WebObjects developers who want to increase their overall knowledge of WebObjects, or those who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects








_______________________________________________ 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: Problem with objectsWithFetchSpecification
      • From: Chuck Hill <email@hidden>
    • Re: Problem with objectsWithFetchSpecification
      • From: Ian Joyner <email@hidden>
References: 
 >Problem with objectsWithFetchSpecification (From: Ian Joyner <email@hidden>)
 >Re: Problem with objectsWithFetchSpecification (From: Chuck Hill <email@hidden>)
 >Re: Problem with objectsWithFetchSpecification (From: Ian Joyner <email@hidden>)
 >Re: Problem with objectsWithFetchSpecification (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Xcode 2.1 & WebObjects 5.3
  • Next by Date: Re: Xcode 2.1 & WebObjects 5.3
  • Previous by thread: Re: Problem with objectsWithFetchSpecification
  • Next by thread: Re: Problem with objectsWithFetchSpecification
  • Index(es):
    • Date
    • Thread