This message was deleted.

Thanks for the detailed writeup @aarona Yes, I agree with you on that session thing that it won’t see it until the session is flushed (response is written) or the session is flushed using

flush: true

. In our case, to overcome this problem, wherever we have used unique mapping, we have made sure that the values of that field/column can never be duplicate or if there are chances, we have used

flush: true

where-able possible (keeping transaction rollback in mind).

Very informative article! I have to agree with @Aaron here actually regarding the database migration. If the uniqueness constraint is being checked by the database then the schema must be updated somehow. Now, it may be in your case that upon the initial migration when the table was created GORM added that database-level constraint because the unique constraint was present. Then subsequently removing the constraint and replacing it with a mapping meant no database change. But if someone is adding a new uniqueness mapping to an existing table it must have a migration.

Not really sure why this isn’t happening for you guys because like I mentioned before, even with a fresh database and unique mapping, it seems to create the unique constraints.

If you guys need a performant way to work around this, you can always create a custom validation which uses a bloom filter

My apologies for being unclear. A fresh database with a unique mapping will create a unique constraint as you have illustrated. What I meant was if there is a table that existed without a unique constraint, and this mapping were added, another migration would be needed to add the database-level unique constraint.

@joem86 Yes, that's what I was saying. If you have an existing schema which is working with a constraint, and you switch it to a mapping, you might need to create a constraint in the database. For our schema, I don't think our unique constraints had db constraints, but some of those were created ages ago with Grails 2 so it might be different now. Still good advice

@joem86 & @aarona thanks for reply, guys! Correct me if I’m wrong. If your existing schema which is working with a constraint that means the table must already have the unique constraint applied. And now when you switch it to mapping and if you do not alter the constraint or do not generate a migration, how that existing constraint will be removed?

The existing constraint will not be removed. I am referring to a scenario where a table does not have a unique constraint or a mapping to begin with. If one is added to the

mapping

of the domain object then a database migration must be generated to add that constraint.

Oh! Now I understand your point.