DuplicateUserEMailAddressException

[12年前 に Andreas Müller によって更新されました。]

Hi,

if I create a new User using UserLocalServiceUtil.addUser(...) with an email address already used for an existing User I get a DuplicateUserEmailAddressException. Many thanks for telling me that in a neat logical checked Exception, Liferay. That's the best practice way to signal a problem which might be soluble at a caller's level. (So far, I can only blame the Liferay API for not providing me the existing user causing trouble in a custom attribute of that Exception class which would be a true first-rate implementation:-)
However, if I change an existing user calling UserLocalServiceUtil.updateUser(User user) and hand in the very same email address, I certainly would expect the very same DuplicateUserEmailAddressException, shouldn't I? But what I get is a SystemException with a cause of class ORMException with a cause of org.hibernate.exceptionGenericJDBCException: could not execute JDBC batch update! I can then only guess that the duplicate email address is now causing a UNIQUE constraint violation at database level which prevents the update from succeeding. Grrrr! If ever that API could be a little bit more consistent and coherent! We are talking here about two similar methods in the same class! Grrrrrr!!!!!!!

Has anybody seen that problem before?

[12年前 に Mika Koivisto によって更新されました。]

That method bypasses all business logic and goes directly to the persistence tier. The corresponding updateUser() method would be:

	public User updateUser(
			long userId, String oldPassword, String newPassword1,
			String newPassword2, boolean passwordReset,
			String reminderQueryQuestion, String reminderQueryAnswer,
			String screenName, String emailAddress, long facebookId,
			String openId, String languageId, String timeZoneId,
			String greeting, String comments, String firstName,
			String middleName, String lastName, int prefixId, int suffixId,
			boolean male, int birthdayMonth, int birthdayDay, int birthdayYear,
			String smsSn, String aimSn, String facebookSn, String icqSn,
			String jabberSn, String msnSn, String mySpaceSn, String skypeSn,
			String twitterSn, String ymSn, String jobTitle, long[] groupIds,
			long[] organizationIds, long[] roleIds,
			List<usergrouprole> userGroupRoles, long[] userGroupIds,
			ServiceContext serviceContext)
		throws PortalException, SystemException</usergrouprole>

[12年前 に Jan Geißler によって更新されました。]

This any maaaany other strange behaviour. You always have to guess, which Mehtods in *LocalServiceUtil to call, which WILL check for problems. Meanwhile if I have to solve a problem where I have to use the Liferay-Core Services, I take a deep look in the sourceCode of that particular *LocalServiceImpl. The total lack of JavaDoc at Interface-Level is also kind of annoying...
I could go on and on, but the real point is:
We need more documentation!

Grüße aus Frankfurt am Main
Jan

[12年前 に Andreas Müller によって更新されました。]

@ Mika Koivisto
Thank you for helping. I will have to base my update process on that method with the many parameters.

@ Jan
I agree with your complaint. Whenever I program against that APIs I suffer. The main shortfalls are:

• Very poor JavaDoc: most projects have little JavaDoc but Liferay's JavaDoc is kind of a travesty
• Layering is poor: e.g. by common practice I would expect UserLocalServiceUtil.updateUser(User) to be the higher (business) level method compared to updateUser(long, String, String,String,...). In reality it seems to be the other way round and in any case both methods should not be in the same class.
• Database keys instead of plain objects are used even in the highest API classes e.g. UserLocalServiceUtil.
• There are always many ways of doing the apparently same thing (and of guessing the difference)
• Classes are often inconsistent: e.g. there is a User.getLocale() method but no User.setLocale(...) method. Why? There is a User.setLanguageId method instead, but everybody knows that Language and Locale are not the same thing. If you decide to use that ony anyway and call User.setLanguageId("de") you will find out that this sets the Locale internally to 'new Locale("de","")' as you might have feared before. Funny: If after setting this you go to the control panel and lookup your user's display settings you will find out that some other language like "Czech" is being displayed. Now you are in for another two days of basic research of Liferay geology. Not sure you will find any sweet oil, though.

Grüße aus München an der Isar
Andreas

[12年前 に Mika Koivisto によって更新されました。]

Andreas Müller:

I agree with your complaint. Whenever I program against that APIs I suffer. The main shortfalls are:

Very poor JavaDoc: most projects have little JavaDoc but Liferay's JavaDoc is kind of a travesty

True. Developer docs have always been somewhat lacking.

Andreas Müller:

Layering is poor: e.g. by common practice I would expect UserLocalServiceUtil.updateUser(User) to be the higher (business) level method compared to updateUser(long, String, String,String,...). In reality it seems to be the other way round and in any case both methods should not be in the same class.

Personally I don't like that those are even exposed to the API but that does allow people do things that might otherwise not be possible through other API methods.

Andreas Müller:

Database keys instead of plain objects are used even in the highest API classes e.g. UserLocalServiceUtil.

That's only way to make it scale. If you've ever developed a Hibernate app that leverages relations you'll quickly notice that it doesn't scale well and if you try to do lazy loading that'll introduce a whole different kinds of problems.

Andreas Müller:

There are always many ways of doing the apparently same thing (and of guessing the difference)

Different service methods usually do different things but there certainly are some cases where the same method name in XXXService and XXXLocalService are doing pretty much different thing and that can be confusing.

Andreas Müller:

Classes are often inconsistent: e.g. there is a User.getLocale() method but no User.setLocale(...) method. Why? There is a User.setLanguageId method instead, but everybody knows that Language and Locale are not the same thing. If you decide to use that ony anyway and call User.setLanguageId("de") you will find out that this sets the Locale internally to 'new Locale("de","")' as you might have feared before. Funny: If after setting this you go to the control panel and lookup your user's display settings you will find out that some other language like "Czech" is being displayed. Now you are in for another two days of basic research of Liferay geology. Not sure you will find any sweet oil, though.

User.getLocale() is a convenience method. User.setLanguageId() takes the Liferay languageId which contains the full locale i.e. de_DE

[12年前 に Andreas Müller によって更新されました。]

Hi Mika,

many thanks for commenting this very carefully and in so much detail.
>User.getLocale() is a convenience method. User.setLanguageId() takes the Liferay languageId which contains the full locale i.e. de_DE
After the usual digging, I have figured out the second part of this statement and implemented it in this way. The first part had to remain kind of a dark suspicion.
The point is that developers spend a lot of time if they stumble into such waters because it is all a bit peculiar and a bit different from what they expect from other systems and from names. Apart time it also costs a lot of motivation to wade through all that again and again.
Liferay could gain a huge benefit from better API docs! If only part of its staff's knowledge were in the docs it would be a dream!

[12年前 に Jan Geißler によって更新されました。]

Andreas Müller:

[...] Apart time it also costs a lot of motivation to wade through all that again and again.
Liferay could gain a huge benefit from better API docs! If only part of its staff's knowledge were in the docs it would be a dream!

100% agreed.....
Nothing more to say.