Remove unique index on email in database

[Kevin Klippenstein, modifié il y a 10 années.]

We are trying to import users from LDAP and we are running into the issue that users with duplicate email address get an error on import. I was able to modify the code through an extension to remove the thrown duplication exception but the database uniqueness constraint is an issue.

So my question is how could I use an extension to remove or override the unique index constraint in the database?

The constraint as I understand it is: unique index IX_615E9F7A on User_ (companyId, emailAddress);

Thanks in advance
Kevin

[Wilson Man, modifié il y a 10 années.]

Liferay Portal expects unique email address for each user within a company, and the portal operates under that assumption. So it is not recommended to change the DB constraint. What is your use case? why do you have duplicate email addresses?

[David H Nebinger, modifié il y a 10 années.]

Yeah, I agree with Wilson, removing the constraint will really break things (especially if you're logging in via email address)...

You can't really do SQL-like things in an EXT w/o coding something up yourself (you could use a global startup action, but you'd have to get the database connection and try to use JDBC to query the meta data to find out if there was an index and manually drop it if it exists).

If you had to remove it, I'd just use your SQL tool to find and drop the index.

But I can tell you that just because you could insert duplicate emails, you're really going to hose up your Liferay environment as a result...

[Kevin Klippenstein, modifié il y a 10 années.]

Thanks for your responses.

Firstly we are going to use screenname as their login so that won't be an issue.

Our situation is that we are importing users in from a pre-existing system where email was neither required or required to be unique. Users may not have a unique email address as they may share a single company email used as a point of contact.

If I do go into the database and simply remove the unique index and add a non-unique index, then would the unique index get added back again on a restart or would upgrades cause the unique index to be re-applied?

Also would you mind expanding upon this statement: "But I can tell you that just because you could insert duplicate emails, you're really going to hose up your Liferay environment as a result..."? What are the risks of allowing duplicate emails in the system?

[David H Nebinger, modifié il y a 10 années.]

Like any system that expects to get a single row as a result of a query because the system expects it to be unique, when the system gets multiple rows instead the outcome is uncertain...

Liferay uses a Lucene index to cache user records, for example. Removing the unique index in the DB may allow them to be stored, but may result in index failures.

Without a thorough review of the code, you'll basically never be sure that the change you're introducing may break something...

[Kevin Klippenstein, modifié il y a 10 années.]

Thanks for your quick and insight response.

Your first point is a very good one and we are going to further consider our options before proceeding with the database change.

Thanks again for the response!

[Atul Patel, modifié il y a 10 années.]

I'm still confused as to the use case..

Why do you have multiple users/user accounts with the the same email address.

I've run into this issue before where a generic email was provided for a number of users that had computer access but not email access.

We ended up adding logic to the import routine to create a unique email address for these type of users in liferay. It was not an ideal solution because Liferay's core business rules rely on the concept of each user having a unique email address. When that rule is not followed a number of different issue arise, some mundane, and some security related.

Hope this helps.

--Atul

[Kevin Klippenstein, modifié il y a 10 années.]

Thanks for the follow-up.

The portal we are creating deals with external users who can come from the same organization. Sometimes the users from the same organization share an email or more correctly use the same general email address from that organization.

We may go down the path of cleansing the email addresses in LDAP before they are imported in. Or we may do something similar to what you did and generate an email for the users with duplicates.