• 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: raw rows post-processing, (im)mutable?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: raw rows post-processing, (im)mutable?


  • Subject: Re: raw rows post-processing, (im)mutable?
  • From: Chuck Hill <email@hidden>
  • Date: Wed, 24 Feb 2016 00:11:49 +0000
  • Thread-topic: raw rows post-processing, (im)mutable?

In theory your more optimized code is relying on an undocumented implementation detail which is bad.  The next release of WO could break your code.  But as Donald Trump has a better chance of being selected as the next Pope than of Apple making a new WO release it seems safe in actual practice.

You could do something like this:

if (needToAddSomething(rr))
    def nrr= rr instanceof NSMutableDictionary ? rr : rr.mutableClone()





On 2016-02-23, 4:04 PM, "webobjects-dev-bounces+chill=email@hidden on behalf of OC" <webobjects-dev-bounces+chill=email@hidden on behalf of email@hidden> wrote:

>Hello there,
>
>well, having fetched raw rows all right, I need to post-process them, essentially by checking each fetched raw row, and to some of them (not all, but many) adding couple of extra attributes.
>
>The safe and clean approach would, of course, be something like
>
>=== safe&clean ===
>def fetchedRawRows=ec.objectsWithFetchSpecification(fs)
>def result=new NSMutableArray()
>for (rr in fetchedRawRows)
>  if (needToAddSomething(rr))
>    def nrr=rr.mutableClone()
>    nrr.setObjectForKey(...) // more of these
>    nrr.removeObjectForKey(...) // when post-processed, some fetched BLOBs are not needed anymore, NSData will be GCed in due time
>    result.addObject(nrr)
>  } else result.addObject(rr)
>return result
>===
>
>in practice though those returned raw rows seem to be mutable (com.webobjects.eocontrol._EOMutableKnownKeyDictionaries, whatever that means), and the unsafe unclean but considerably more efficient approach actually seems to work:
>
>=== quick&dirty ===
>def fetchedRawRows=ec.objectsWithFetchSpecification(fs)
>for (rr in fetchedRawRows)
>  if (needToAddSomething(rr)) {
>    rr.setObjectForKey(...) // more of these
>    rr.removeObjectForKey(...) // unlike above, might be GCed immediately if need be
>  }
>return fetchedRawRows
>===
>
>Since fetchedRawRows will tend to be rather at the huge side, quite probably the difference will be notable.
>
>Can someone say by experience or by a deep knowledge that the quick&dirty approach is actually safe? Or, contrariwise, that if I embrace it, sooner or later the hell will break loose?
>
>Thanks!
>OC
>
>
> _______________________________________________
>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

 _______________________________________________
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


References: 
 >raw rows post-processing, (im)mutable? (From: OC <email@hidden>)

  • Prev by Date: raw rows post-processing, (im)mutable?
  • Next by Date: Re: ERDDelayedBooleanAssignment question
  • Previous by thread: raw rows post-processing, (im)mutable?
  • Next by thread: Use case for a "case insensitive equals" qualifier
  • Index(es):
    • Date
    • Thread