• 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: Fetch Spec Misunderstanding
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fetch Spec Misunderstanding

  • Subject: Re: Fetch Spec Misunderstanding
  • From: "Jerry W. Walker" <email@hidden>
  • Date: Wed, 27 Jul 2005 11:07:57 -0400
Hi, Darich,

On Jul 27, 2005, at 9:20 AM, Darich Runyan/OMNI INFOSEC LTD HQ wrote:

Thanks for the ideas. I fooled around with this some and was never able to
get it to work. Maybe I am going about this the wrong way. Is there a
better way to obtain just a single column from the database that is just the
values and not the key/value pair?

Thanks,
Darich

Yes, use a SQL solution. So long as you're thinking in terms of columns in a relational database and their values, you're thinking in the terms around which SQL, as a language, is wrapped. I'll paraphrase a message I posted on another thread regarding this same issue.

The question is framed from the perspective of "I have a table of rows with which I want to do something, now how do I get WO to help me do that thing to my table in the same way I've always done these things with SQL?"

Experienced WO developers would think instead of the object graph that we are manipulating in our object oriented Java application rather than the rows we have stored in our relational database. Rephrasing the question, "I have a set of objects 'O' with an attribute 'a'. How do I obtain the value of that attribute for each of those objects?"

The obvious answer to your original question is dump WebObjects. It's a poor technology for doing pure SQL manipulation. Just issue a SQL "select myColumn from myTable;" and live with the rest of SQL's shortcomings as an enterprise application development technology.

On the other hand, if you want to use WebObjects, you'll find it much easier to think in the terms in which it frames the questions, namely classes, objects, object graphs and object oriented concepts. In these terms, the database is more appropriately thought of as an "object store", or place to hold my objects rather than a relational database. In these terms, you'll find it much easier to simply fetch the objects from the database and extract their values as you would the values of any other objects.

Perhaps those objects have already been cached and we don't need to fetch raw rows. That is, if they've already been fetched earlier for some other operation, their snapshots are already cached in memory and we would have been doing a redundant fetch rather than economizing.

Failing those possibilities, I would still write the fetch without referencing raw rows and get it to work. Then, if the result is clearly taking too long or requiring too much memory, I would profile where the delays are occurring or the memory is being consumed and, if in database fetches, then would start to consider raw rows. The point being that referencing raw rows is a last resort rather than a way to move into the comfort zone of old habits with result sets.

So what are the down sides to just moving immediately to raw rows?

  * a missed opportunitiy to get used to the WO way

* the short circuiting of several elegant features built into WO to help one deal with objects rather than rows

* potential extra database accesses to objects already cached in memory

* the higher probability of weak object oriented design built up from this raw row decision

If you take the natural WebObjects route and stop trying to get a single value out of a table, the advice I gave in my earlier response still holds in general. Except, instead of dealing with NSDictionaries, you will be dealing with Enterprise Objects, or EOs. The code sample I supplied would look more like this, in that case:

Presume that myFetchSpec exists, that the class name for the EO that you've persisted in that table of the database is MyObject, that the name of the element of that class whose value you are interested in is myAttribute, and that you've fetched an array named myObjects as follows:

NSArray myObjects = myEditingContext.objectsWithFetchSpecification(myFetchSpec); // Fetches instances of MyObject

NSDictionary anObject; // Iteration variable
NSDictionary selectedObject; // used to hold selected element from WOPopUpButton

Now, set up your WOPopUpButton with the following bindings:

     list = myObjects;
     item = anObject;
     displayString = anObject.myAttribute
     selection = selectedRow

You'll find this easier, in general, than working with the raw rows, because you can do the bindings visually and directly in WebObjects Builder rather than having to type them in as you would have to do with the NSDictionaries resulting from a raw rows fetch. The WOPopUpButton should display what you want.

Good luck with WebObjects.

Best regards,
Jerry

From: "Jerry W. Walker" <email@hidden>
Date: Wed, 27 Jul 2005 00:45:27 -0400
To: Darich Runyan/OMNI INFOSEC LTD HQ <email@hidden>
Cc: WebObjects Development <email@hidden>
Subject: Re: Fetch Spec Misunderstanding

Hi, Darich,

Raw fetches return NSArrays of NSDictionaries, of which, an
EOMutableKnownKeyDictionary is probably a subclass (I'm not really
familiar with it, per se).

So long as it's an NSDictionary, you should simply be able to bind
your pop-up button to the key name of the key-value pair you
retrieved and it should display only the value based on that key. The
fact that each of your dictionaries in the array contains only one
key-value pair, notwithstanding.

So, presume that myFetchSpec exists and that you've fetched an array
named myObjects as follows:

     NSDictionary aRow;  // Iteration variable
     NSDictionary selectedRow;  // used to hold selected element from
WOPopUpButton
     myFetchSpec.setRawRowKeyPaths(new NSArray
( "myAttribute" );    // sets the keypath for fetching raw rows with
only one key-value pair
     NSArray myObjects =
myEditingContext.objectsWithFetchSpecification(myFetchSpec);  //
Fetches raw rows as specified above

Now, set up your WOPopUpButton with the following bindings:

     list = myObjects;
     item = aRow;
     displayString = aRow.myAttribute
     selection = selectedRow

Replace "myAttribute", of course, with the name of the attribute that
you want displayed. The WOPopUpButton should display what you want.

The above was done from memory, so may contain errors.

Regards,
Jerry

On Jul 27, 2005, at 12:14 AM, Darich Runyan/OMNI INFOSEC LTD HQ wrote:


I found out a bit more.  Looks like the Raw Fetch is returning a
EOMutableKnownKeyDictionary which is not quite what I want.  Seems
that I
need to be using a formatter.  Is there any good docs on how to set
one of
these up?

Thanks,
Darich



From: Darich Runyan/OMNI INFOSEC LTD HQ <email@hidden>
Date: Tue, 26 Jul 2005 23:41:05 -0400
To: WebObjects Development <email@hidden>
Subject: Fetch Spec Misunderstanding

All,

This solution to the problem I am having should be easy yet I am
unable to
find an answer. Up until this evening my application has only
allowed users
to input data and return complete sets via WORepetitions. This works
nicely. I now have a request to provide just portions of a
certain tables,
specifically a single column from each that will then be used to
populate a
WOPopUpButton. To do this I have created a Raw Fetch
Specification in the
EOModel that returns just the column that I want from the entity.
This
almost works fine except it returns the values in the following
format:

{columnName = "value";}

So my PopUpButton gets populated with a bit of extraneous
information.  Do I
have to parse this prior to creating the WOPopUpButton in order to
only have
the values added to it or is there some way to have the fetch spec
just
return the value sans the column name?

Thanks,
Darich


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:



infosec.co> m


This email sent to 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:
40codefab.com

This email sent to email@hidden




--
__ Jerry W. Walker, Partner
     C o d e F a b, LLC - "High Performance Industrial Strength
Internet Enabled Systems"
     email@hidden
     212 465 8484 X-102  office
     212 465 9178        fax








--
__ Jerry W. Walker, Partner
C o d e F a b, LLC - "High Performance Industrial Strength Internet Enabled Systems"
email@hidden
212 465 8484 X-102 office
212 465 9178 fax


_______________________________________________
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: Fetch Spec Misunderstanding

      • From: Darich Runyan/OMNI INFOSEC LTD HQ <email@hidden>
      • 





References: 


 >Re: Fetch Spec Misunderstanding (From: Darich Runyan/OMNI INFOSEC LTD HQ <email@hidden>)






    

  • Prev by Date:
Login Area - No Backtracking through History

    • 

  • Next by Date:
Re: Tomcat build & deployment idiot's guide needed

    • 

  • Previous by thread:
Re: Fetch Spec Misunderstanding

    • 

  • Next by thread:
Re: Fetch Spec Misunderstanding

    • 

  • Index(es):

      

    • Date
      • 

    • Thread
      • 

    

    •