Hi, I found a weird behavior: I've got my table defined like this:

object Profiles : IntIdTable() {
  val email = varchar("email", 50).uniqueIndex() // important!
  val name = varchar("name", 50)
}

Looking at the logs, it seems that the table is created correctly by Exposed:

DEBUG Exposed - CREATE TABLE IF NOT EXISTS Profiles (id INT AUTO_INCREMENT PRIMARY KEY, email VARCHAR(50) NOT NULL, name VARCHAR(50) NOT NULL)
DEBUG Exposed - ALTER TABLE Profiles ADD CONSTRAINT Profiles_email_unique UNIQUE (email)

Because of the unique index, I would expect

insert

requests with an email already present in the database, to fail:

Profiles.insert { profile ->
  profile[this.email] = email
  profile[this.name] = name
}

In the above example, I would expect an

insert

to be fail if the email is already used by another profile. Nothing seems weird in debug either;

DEBUG Exposed - INSERT INTO Profiles (email, name) VALUES ('some random <http://email.fr|email.fr>', 'my full name')

However, when running this code multiple times, instead of failing on the

insert

, it simply replaces the previous entry that had the same email. In case it's relevant, I'm using MariaDB. For obvious reasons, I don't want users of the software to be able to replace other accounts. I'm not sure if the current behavior is 'normal' or 'bugged', so I'm asking here whether: 1. Is it normal behavior, or should I submit a bug report? 2. If this is normal behavior, what should I change in my code so the

insert

fails (with an exception or something else)?

Have you tried removing exposed from the equation and doing the same directly with MariaDB?

Copy-pasting the debug lines in a MariaDB console gives:

[23000][1062] (conn=3) Duplicate entry 'some random <http://email.fr|email.fr>' for key 'Profiles_email_unique'

So I think it's safe to assume this is an Exposed bug. Reported as https://github.com/JetBrains/Exposed/issues/1212