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
Given an email constraint, the first .build() generates the correct email. But the second time .build() is called it generates the value x which is not a valid email. I know there are limitations with unique but it is odd it generates the right data the first time & not the second. Note that even unique: false causes this.
It works for me when I remove the unique constraint. It should stop populating data once the EmailConstraintHandler builds the email, but when it's unique that email address fails validation so it continues through the handler chain and eventually the blank handler puts the X in (as you see in the logs).
I'm not sure why it worked before for the unique: true case. For unique constraints, we usually just add something to TestDataConfig to generate a sequence of values.
I do have plans to add proper unique support as part of a second round of refactoring.
Ok, this seems like a GORM issue. Specifying unique: false has the same behavior as unique: true. I think they are just checking for the existence of the constraint and not the actual value. I created a test in BTD:
Given an email constraint, the first
.build()
generates the correct email. But the second time.build()
is called it generates the valuex
which is not a valid email. I know there are limitations with unique but it is odd it generates the right data the first time & not the second. Note that even unique: false causes this.See example spec here https://github.com/erichelgeson/btdIssue/blob/master/src/test/groovy/test/FooControllerSpec.groovy
This did work in b-t-d 3.0.1 & Grails 3.2.11
Environment: Grails 3.3.2, b-t-d 3.3.0.RC1, Mac OSX 10.13.2, JDK 8u152
The text was updated successfully, but these errors were encountered: