Paranoid with unique constraint

Issue Creation Checklist

• I understand that my issue will be automatically closed if I don’t fill in the requested information
• I have read the contribution guidelines

Bug Description

When we try to insert a record into a table with paranoid: true that has a soft deleted record with a similar unique field, a validation error is being thrown.

Reproducible Example

  class User extends Model {}

  User.init({
    username: {
      type: DataTypes.TEXT,
      allowNull: false,
      unique: true
    },
  }, {
    sequelize,
    modelName: 'User',
    paranoid: true,
  });
  
  const user = await User.create({
    username: 'foo',
  });
  
  await user.destroy();
  
  user.isSoftDeleted(); // true
  
  const anotherUser = await User.create({
    username: 'foo',
  }); // Fails

What do you expect to happen?

The creation of anotherUser should be successful, maybe by using upsert internally to change the createdAt timestamp to current date and deletedAt to null when a matching soft deleted record is found.

What is actually happening?

Validation error is being thrown.

Environment

• Sequelize version: 6.x.x
• Node.js version: 16.6.2
• If TypeScript related: TypeScript version: No significance.
• Database & Version: Postgres 14
• Connector library & Version: pg

Would you be willing to resolve this issue by submitting a Pull Request?

• Yes, I have the time and I know how to start.
• Yes, I have the time but I will need guidance.
• No, I don’t have the time, but my company or I are supporting Sequelize through donations on OpenCollective.
• No, I don’t have the time, and I understand that I will need to wait until someone from the community or maintainers is interested in resolving my issue.

---

Indicate your interest in the resolution of this issue by adding the 👍 reaction. Comments such as “+1” will be removed.

[zignis]

It is database behaviour and should not be avoided by doing reset on the deleted_at field, why?

Because you didn’t actually delete the unique field, it is normal when you get the validation thrown error when you inserts the same username.

To solve this you must delete the record completely with it’s associations instead of soft deleting it.

upsert does not update the primary key, and it is dangerous for relationships, you should not using soft delete (to replace it with the new different user with the same primary key) for one-to-many associations, if you saving some transactions records, save it as historical data.

Reset the deleted_at to null back is not best practice.

Makes sense 👍

[fzn0x]

It is database behaviour and should not be avoided by doing reset on the deleted_at field, why?

Because you didn’t actually delete the unique field, it is normal when you get the validation thrown error when you inserts the same username.

To solve this you must delete the record completely with it’s associations instead of soft deleting it.

upsert does not fit to update the primary key, and it is dangerous for relationships, you should not using soft delete (to replace it with the new different user with the same primary key) for one-to-many associations, if you saving some transactions records, save it as historical data.

Reset the deleted_at to null back is not best practice.