'where' method is modifying the receiver

[primableatom]

The 'where' method in has_many relation is modifying the receiver in a special case

assignees = task.assignees
assignees.where(:assignee_name => "Assignee 1") # this changes the assignees count to 1

[sxross]

Are you using the ArrayModelAdapter?

[primableatom]

Yes, it is with ArraymodelAdapter. Found this issue while wanting to reload a UITableView based on some filter criteria. We were passing the collection (the value returned by task.assignees for example). Found out this issue of the collection being set to the return value of the where function.

Strangely this issue happens only when assigning the collection to a variable and works fine for task.assignees.where(:name).eq("Assignee 1") # doesn't modify task.assignees

[DougPuchalski]

ArrayFinderQuery modifies the collection passed in. Might want to pass collection.dup in the find method.

[sxross]

This worries me ever so slightly as it relies in GC to clean up. Is there a way to monitor its life cycle and release manually, so as to be a good citizen?

Sent from my iPhone

On Jul 2, 2013, at 7:52 AM, Doug Puchalski [email protected] wrote:

ArrayFinderQuery modifies the collection passed in. Might want to pass collection.dup in the find method.

—
Reply to this email directly or view it on GitHub.

[DougPuchalski]

Not sure who you're asking, or to work around such a fundamental flaw in RM... but the alternative might be to just not modify the collection in ArrayFinderQuery, no?

[sxross]

Asking anyone/everyone participating in this issue. GC in Ruby is pretty iffy and Rails suffered from memory bloat for a long time before they went on a real hard-core diet. But with Rails you can always throw more iron at the problem. Not so with iOS apps.

On the other side of this is the fact that although it's a pain to do, we can explicitly retain and release stuff even though it makes things difficult to debug. Is it worth it? Am I solving a problem that doesn't exist?

On Jul 2, 2013, at 11:43 AM, Doug Puchalski [email protected] wrote:

Not sure who you're asking, or to work around such a fundamental flaw in RM... but the alternative might be to just not modify the collection in ArrayFinderQuery, no?

—
Reply to this email directly or view it on GitHub.

[DougPuchalski]

I feel like if we're worried about RM not disposing of objects, there are bigger fish to fry across the entire library, and apps in general. Any reason you're worried about this specific example?

On Jul 2, 2013, at 12:27 PM, "s.ross" [email protected] wrote:

Asking anyone/everyone participating in this issue. GC in Ruby is pretty iffy and Rails suffered from memory bloat for a long time before they went on a real hard-core diet. But with Rails you can always throw more iron at the problem. Not so with iOS apps.

On the other side of this is the fact that although it's a pain to do, we can explicitly retain and release stuff even though it makes things difficult to debug. Is it worth it? Am I solving a problem that doesn't exist?

On Jul 2, 2013, at 11:43 AM, Doug Puchalski [email protected] wrote:

Not sure who you're asking, or to work around such a fundamental flaw in RM... but the alternative might be to just not modify the collection in ArrayFinderQuery, no?

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

[sxross]

Yeah, probably best to watch usage and see what the RM-3 fix does for us.

On Jul 2, 2013, at 5:34 PM, Doug Puchalski [email protected] wrote:

I feel like if we're worried about RM not disposing of objects, there are bigger fish to fry across the entire library, and apps in general. Any reason you're worried about this specific example?

On Jul 2, 2013, at 12:27 PM, "s.ross" [email protected] wrote:

Asking anyone/everyone participating in this issue. GC in Ruby is pretty iffy and Rails suffered from memory bloat for a long time before they went on a real hard-core diet. But with Rails you can always throw more iron at the problem. Not so with iOS apps.

On the other side of this is the fact that although it's a pain to do, we can explicitly retain and release stuff even though it makes things difficult to debug. Is it worth it? Am I solving a problem that doesn't exist?

On Jul 2, 2013, at 11:43 AM, Doug Puchalski [email protected] wrote:

Not sure who you're asking, or to work around such a fundamental flaw in RM... but the alternative might be to just not modify the collection in ArrayFinderQuery, no?

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.