Datamapper DataMapper → 1.1.1

Comments and changes to this ticket

• You flagged this item as spam.
  

  Carl Porth January 13th, 2010 @ 05:19 PM

  << fails to invoke dirty tracking so calling save fails to see any changes.

  This raises a larger issue about how to handle methods on attributes which modify the receiver therefore bypassing dirty tracking.

  3 approaches to handle this:

  1. Document this issue as an implementation detail for the user
     
  2. Override receiver modifying methods to invoke dirty tracking
     
  3. Freeze the attribute so it cannot be modified; the user has to reassign changes

  I like approach 3. A simple fix that works across all kinds of properties and works with dirty tracking. It also makes it hard to accidentally change an attribute without reassigning it.

• You flagged this item as spam.
  

  Carl Porth January 13th, 2010 @ 06:00 PM

  For example, you could do:

  • freeze_attribute.diff 1.5 KB

• You flagged this item as spam.
  

  Austin Bales (at 417east) January 13th, 2010 @ 10:51 PM

  I see your reason for supporting approach 3, but it seems an unusual restriction to set (perhaps I'm uninformed). However, if the behavior is atypical, then it sort of presents a usability issue.
  Is it that approach two is too complex or costly? I'm by no means a Ruby expert, but bear with me...

  Because the Flag type contains multiple values, and is represented as an array, it seems logical that I can push things into it. One of the reasons I appreciate DataMapper is that it does feel like "All Ruby All The Time", and things work naturally. I think this is especially important if #1128's conclusion was that Flag should yield arrays.

• You flagged this item as spam.
  

  Carl Porth January 14th, 2010 @ 01:48 AM

  I don't think your example is atypical at all; consider the following case with calling capitalize! on a string attribute: http://gist.github.com/276969

  Receiver modifying methods seem to be a weakness with the current implementation of dirty tracking. ActiveRecord addresses this by requiring you to call #{attribute}_will_change! before modifying the receiver.

  Maybe there is a better pattern or ruby idiom to solve this?

• You flagged this item as spam.
  

  Austin Bales (at 417east) January 21st, 2010 @ 06:33 PM

  I don't love #attribute_will_change!, but what if you could set values to explicitly save.

  p = Person.get(3)
  p.first_name.capitalize!
  p.visits << Visit.new()
  p.save :first_name, :visits
  

• 

  Dan Kubb (dkubb) February 2nd, 2010 @ 12:24 PM

  • State changed from “new” to “unconfirmed”
  • Assigned user cleared.
• 

  Dan Kubb (dkubb) May 22nd, 2010 @ 01:40 AM

  • Assigned user set to “Piotr Solnica (solnic)”
• 

  Piotr Solnica (solnic) May 26th, 2010 @ 03:53 AM

  • State changed from “unconfirmed” to “confirmed”

  This is going to be resolved in 1.x.x series as it requires changes in dm-core and we won't make it for 1.0.0

• 

  Piotr Solnica (solnic) January 16th, 2011 @ 05:07 AM

  • Milestone set to “1.1.1”
  • Milestone order changed from “0” to “0”
• 

  Dan Kubb (dkubb) March 16th, 2011 @ 10:41 PM

  [bulk edit]