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
{{ message }}
This repository has been archived by the owner on Dec 12, 2021. It is now read-only.
Given the above associations, say a Location has 5 DIDs and 0 Screened DIDs. On the nested form, I add 5 rows of Screened DIDs, all having the same selected :did_id. Because there were zero Screened DID records for this location before the transaction, all nested objects will be created with different ids but the same :did_id.
If I have 1 Screened DID present with a did_id: 500, and I attempt to create/update one other object with the same, the validation will kick in.
If I have 2 Screened DID objects with different :did_id (500 and 501), and I update both to have the same (502), then the validation will fail, like in the first scenario.
Say in one transaction I attempt to delete ScreenDID id: 1 and create a second record with the :did_id of the first. The form is bounced back, because the :did_id was already present before the transaction, even if the first record was supposed to be deleted.
Finally, if two records are saved in this manner, and are unchanged on the next form update, the two original records will not vall invalid uniqueness. In theory, it should since the objects were in the database before the transaction. I think the validation does not work because they were simply submitted already, and are for some reason exempt from comparing each other.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Rails 4.2.0, nested_form 0.3.2
TL;DR - The
validates_uniqueness_on
method only compares current records at their current state before the form was submitted.Given the above associations, say a Location has 5 DIDs and 0 Screened DIDs. On the nested form, I add 5 rows of Screened DIDs, all having the same selected
:did_id
. Because there were zero Screened DID records for this location before the transaction, all nested objects will be created with different ids but the same:did_id
.If I have 1 Screened DID present with a
did_id: 500
, and I attempt to create/update one other object with the same, the validation will kick in.If I have 2 Screened DID objects with different
:did_id
(500
and501
), and I update both to have the same (502
), then the validation will fail, like in the first scenario.Say in one transaction I attempt to delete ScreenDID
id: 1
and create a second record with the:did_id
of the first. The form is bounced back, because the:did_id
was already present before the transaction, even if the first record was supposed to be deleted.Finally, if two records are saved in this manner, and are unchanged on the next form update, the two original records will not vall invalid uniqueness. In theory, it should since the objects were in the database before the transaction. I think the validation does not work because they were simply submitted already, and are for some reason exempt from comparing each other.
The text was updated successfully, but these errors were encountered: