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

Re: EOFetchSpecification with SQL


  • Subject: Re: EOFetchSpecification with SQL
  • From: John Boynton <email@hidden>
  • Date: Fri, 22 Aug 2003 15:56:48 -0600

Jonathan Rochkind wrote:
If you use an EOFetchSpecification, as I explained above, you _can_ specify the raw SQL yourself. If you want actual EOs to be returned, you've got to make sure the right columns are returned in the right order. If you later add columns in EOModeler, it may break your hard coded SQL, which is another reason to avoid it.

I've been playing with hints because in some circumstances EO doesn't generate the correct where clause for qualifiers involving to-many key paths. You can avoid hard-coding your SQL by getting the attributes from EOEntity.attributesToFetch(). (At least this seems to be the right method to use in the little testing I've done - anyone care to corroborate? So, to generate a select list for the hints, I use


   public static String hintsSelectList(EOEditingContext ec,
    String entityName, String tableAlias) {

      StringBuffer selectList = new StringBuffer();
      EOEntity entity = EOUtilities.entityNamed(ec, entityName);
      NSArray attributes = entity.attributesToFetch();
      if (null != attributes) {

         Enumeration attrEnum = attributes.objectEnumerator();
         while (attrEnum.hasMoreElements()) {

            EOAttribute eachAttr = (EOAttribute)attrEnum.nextElement();
            if (selectList.length() > 0) selectList.append(", ");

selectList.append(tableAlias).append(".").append(eachAttr.columnName());
         }
      }
      return selectList.toString();
   }

If tableAlias is "t0", this generates a select list like "t0.COL_NAME_1, t0.COL_NAME_2, ...", which you can flesh out with the rest of the query. Then (theoretically) the query will still work if you add or delete attributes later on.

If you really want to avoid table and column names in your code, you can get any of these external names from EO, so you can construct a query in Java which will not need to be modified if external names change. I find though that aside from the extra time it takes to do it, the code is less readable, so it's a tradeoff between development time and readability on the on hand, and adaptability on the other.

John
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.

  • Prev by Date: Re: New WO book - "WebObjects 5 for Mac OS X"
  • Next by Date: Re: problem with the size of submit button
  • Previous by thread: Re: EOFetchSpecification with SQL
  • Next by thread: Upload with Direct action
  • Index(es):
    • Date
    • Thread