#1284 ✓resolved
gucki

not dirty fields get updated when using update on association

Reported by gucki | May 21st, 2010 @ 08:33 AM

To reproduce the probleme please look here:
http://pastie.org/971086

The update sql commands look like:
~ (0.000034) UPDATE "members" SET "position" = 3, "test_id" = 1 WHERE "id" = 1 ~ (0.000031) UPDATE "members" SET "position" = 1, "test_id" = 1 WHERE "id" = 3

But as test_id has never been changed, it should not be included in the update.

Versions: dm-1.0.0.rc2, ruby-1.9.2-head

BTW: I wonder why a default "order by id" clause is appended to all queries. Is this another bug? How can this be omitted?

Comments and changes to this ticket

  • gucki

    gucki May 21st, 2010 @ 08:54 AM

    When using dm-rails, there are problems. When adding a Date(Time) field to Member, this always gets updated too. I think this might be caused by some timezone stuff which makes the fiekd dirty while in fact it's not been changed.

    The problem with the Date(Time) field is real problematic when you Try to update like this:

    Team.first.members.all(:fields => [:id, :position]).each do |item|
      item.update(:position => ids.index(item.id)+1)
    end
    

    This raises an exception:
    DataMapper::UpdateConflictError (Member#update cannot be called on a dirty resource)

  • Piotr Solnica (solnic)

    Piotr Solnica (solnic) May 21st, 2010 @ 10:14 AM

    • State changed from “new” to “confirmed”

    Looks like in ManyToOne::Relationship#set the test_id FK is marked as dirty. I can confirm that behaviour.

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) May 21st, 2010 @ 12:53 PM

    I can confirm this behaviour too.

    The implicit ordering of collections is not a bug though. It's required to get non-ambiguous results from queries. If you perform the same query on different datastores, with no order, you'll see that the results are nondeterministic. Some datastores are completely random, while others will order by the primary or unique key. In the case of the latter, people who only use a few datastores are surprised when the new datastore returns results completely differently from what they had before. While this can be an annoyance, it can also be dangerous in cases where you are limiting the records, and possibly performing some action on them.

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) May 21st, 2010 @ 04:30 PM

    • State changed from “confirmed” to “resolved”

    (from [98ae7a1a4f95e23a836a1e3e3d36d33bffd5d51b]) Moved guard clauses for state transition into State #commit methods

    • Update state objects to handle setting the FKs directly.
    • Make sure the child key changes if the parent key changes.

    [#1284 state:resolved] http://github.com/datamapper/dm-core/commit/98ae7a1a4f95e23a836a1e3...

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 »

Referenced by

Pages