You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Create an instance of the model (w = Widget.create!)
Destroy the instance (w.destroy)
Call w.version_at(Time.now)
Expected behavior:
Returns nil (symmetric with calling version_at with a timestamp before the instance was created)
Actual behavior:
Returns the instance of the model (w)
Note that in this case, you could at least call w.destroyed? to see if it was destroyed. But if you use the solution mentioned in #204, which reifies the latest non-destroyed version of the object and then calls version_at, your call to destroyed? will return false.
I'm assuming this isn't intended behavior, but maybe I'm missing something?
It looks like the issue is here, where version_at sees that it can't find an entry in the versions table with a late enough timestamp. It then assumes that the object is live and further assumes that self is the live version of the object.
I overrode version_at in my model with the following, which calls find_by on the model class if there's no entry in the versions table to reify. That should return the live instance if one exists or nil if it's been destroyed. (I avoided find since that would raise an exception if the object has been destroyed.) I'm not sure if this causes other issues or if it'd need to be adjusted to deal with primary keys that are not called "id".
# Returns the object (not a Version) as it was at the given timestamp.defversion_at(timestamp,reify_options={})# Because a version stores how its object looked *before* the change,# we need to look for the first version created *after* the timestamp.v=send(self.class.versions_association_name).subsequent(timestamp).firstv ? v.reify(reify_options) : self.class.find_by(id: id)end
The text was updated successfully, but these errors were encountered:
I believe this is the same issue as #354. There is a PR (#375) which contains a proposed fix for this type of thing. Look for this to be remedied in version 3.1.0.
I might be misunderstanding, but I don't think this is the same issue. This isn't really related to the timestamps, as far as I can tell--if you wait a while between my steps 3 and 4 above, you should get the same thing. The problem is that in the first line below, v is assigned nil if the object has been destroyed (because there are no versions after the timestamp if the timestamp is after the object has been destroyed). Then, the second line returns self, which makes some sense for a live object, but doesn't make sense (at least to me) for an object that has been destroyed. Note especially that self can be a reified old version of the object, which leads version_at to say that the version after destruction is that old version.
Thanks for clarifying, sorry for the confusion, I should've read the initial issue report a little more closely. I agree with your assessment of how the method should behave, and I believe 3323f21 should correct the issue.
Steps to reproduce:
Expected behavior:
Returns nil (symmetric with calling version_at with a timestamp before the instance was created)
Actual behavior:
Returns the instance of the model (w)
Note that in this case, you could at least call w.destroyed? to see if it was destroyed. But if you use the solution mentioned in #204, which reifies the latest non-destroyed version of the object and then calls version_at, your call to destroyed? will return false.
I'm assuming this isn't intended behavior, but maybe I'm missing something?
It looks like the issue is here, where version_at sees that it can't find an entry in the versions table with a late enough timestamp. It then assumes that the object is live and further assumes that self is the live version of the object.
I overrode version_at in my model with the following, which calls find_by on the model class if there's no entry in the versions table to reify. That should return the live instance if one exists or nil if it's been destroyed. (I avoided find since that would raise an exception if the object has been destroyed.) I'm not sure if this causes other issues or if it'd need to be adjusted to deal with primary keys that are not called "id".
The text was updated successfully, but these errors were encountered: