#1161 confirmed
Austin Bales (at 417east)

dm-types Flag fails to persist values assigned with the left shift operator.

Reported by Austin Bales (at 417east) | December 20th, 2009 @ 11:26 PM | in 1.1.1

DataMapper::Types::Flag caches values assigned/appended with the left shift << operator, but fails to persist them on save().

I've created a gist to illustrate the problem.

I might also add that finders like Model.all(:flagprop => [:one, :two]) do not behave as (I) expected, but I really have no idea how they are supposed to work.

See also:

Comments and changes to this ticket

  • Carl Porth

    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.

  • Carl Porth
  • Austin Bales (at 417east)

    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.

  • Carl Porth

    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?

  • Austin Bales (at 417east)

    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.visits << Visit.new()
    p.save :first_name, :visits
  • Dan Kubb (dkubb)

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

    • State changed from “new” to “unconfirmed”
    • Assigned user cleared.
  • Dan Kubb (dkubb)

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

    • Assigned user set to “Piotr Solnica (solnic)”
  • 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)

    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)

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.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »