
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 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) 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) 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) 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.
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
Referenced by
-
1284 not dirty fields get updated when using update on association [#1284 state:resolved] http://github.com/datamapper/dm-c...