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,
"[email protected] on behalf of OC"
<[email protected] on behalf of
[email protected]> 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 protected])
>Help/Unsubscribe/Update your Subscription:
>https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com
>
>This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
