In memory associations
Reported by David James | July 28th, 2008 @ 07:01 PM
Here, I wrote specs (not currently passing) for in-memory associations: http://github.com/sam/dm-core/co...
Sam, Dan, and I discussed this on #dm-hacking this afternoon.
Comments and changes to this ticket
-
David James July 28th, 2008 @ 08:59 PM
During our discussion, I asked Sam something along the lines of: "If we say that associations should be tracked in memory even if the related models are not saved to the database, are we not moving in the direction of tracking all unsaved models in memory? If so, does that mean we are moving down the 'slippery slope' to the point where we expect the following" (Sam's example): @cow = Cow.new; Cow.all.entries.should include(@cow)
Sam had written earlier that the behavior he wants to see is: @cow = Cow.new; Cow.all.entries.should_not include(@cow)
Sam wrote: "the difference is that in [the in-memory specs] you're not using a finder. You're making an explicit assignment. Even if one side was saved and a finder was issued on the association load, it should still contain the item(s) you explicitly added. ... so I think the line for me is that finders don't go out and find unsaved data. But association methods shouldn't clear out assigned data when their finder is triggered.""
-
David James July 29th, 2008 @ 11:18 AM
New specs for one-to-many associations here:
0f60efdecf9d9e265c6dc2385b22b661f6ff0599
-
Dan Kubb (dkubb) December 4th, 2008 @ 02:29 AM
- State changed from “new” to “confirmed”
- Assigned user cleared.
These specs should be used for verification of behavior of associations in dkubb/dm-core.
-
Dan Kubb (dkubb) January 8th, 2009 @ 04:43 AM
- State changed from “confirmed” to “accepted”
- Assigned user set to “Dan Kubb (dkubb)”
-
Dan Kubb (dkubb) June 16th, 2009 @ 03:35 AM
- Milestone set to “0.10.0”
-
Dan Kubb (dkubb) August 15th, 2009 @ 12:05 PM
- Milestone changed from “0.10.0” to “0.10.1”
-
Dan Kubb (dkubb) October 4th, 2009 @ 09:33 PM
- Milestone changed from “0.10.1” to “0.10.2”
[project:id#20609 not-tagged:"0.10.0" not-tagged:"0.10.1" milestone:id#51895 bulk edit command]
-
Dan Kubb (dkubb) February 1st, 2010 @ 04:33 PM
- Milestone changed from “0.10.2” to “1.0.0”
-
-
-
Dan Kubb (dkubb) February 2nd, 2010 @ 02:47 AM
- State changed from “accepted” to “confirmed”
-
Dan Kubb (dkubb) February 4th, 2010 @ 01:32 AM
- State changed from “confirmed” to “duplicate”
I am going to combine this with ticket #418, which has alot more discussion and information for a potential fix to this long standing issue.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
People watching this ticket
Dan Kubb (dkubb)
Tags
Referenced by
-
939
Assigning a parent to a child does not work the same as assigning a child to a parent
This ticket actually goes back quite a way to #488. I'm
g...