INSERT Statement with the duplicated key

Hi all,

I am debugged on TRANSLATION module for [objectId = 680] which is Vietnam orgunit in my database.

Step 1: I have a try at inserting manually one row into TRANSLATION table, more referencing on the enclosed example.

Step 2: I started-up on tomcat again. Checking the Translation of [680]. I saw that the list of Locale where showed two locales (one is “en_GB” default, the left one is “zh_CN” that I made in step 1). (See the picture No.1)

Step 3: I clicked on to choose “zh_CN” locale but none of its property could be loaded (See the picture No.2)

Step 4: I set the new values for each field and then save them again. It’s successful.

Step 5: Checked the current database. It’s really strange (See the picture No.3)

Step 6: Checked Translation table’s details ***(See the picture No.4)***. We could recognize that four attributes: objectClass, objectId, locale, objectProperty as a primary key.

So, is this a bug in Postgresql database or from TRANSLATION module?

**Review the issue which I mentioned in “TRANSLATION PROBLEM” email.

Why don’t we use the locales of the User Setting instead of locale database for TRANSLATION module ???**

···


Hieu.HISPVietnam
Good Health !

Sorry forgot these attached files …

Thanks !

···

On Mon, Oct 26, 2009 at 3:10 PM, Hieu Dang Duy hieu.hispvietnam@gmail.com wrote:

Hi all,

I am debugged on TRANSLATION module for [objectId = 680] which is Vietnam orgunit in my database.

Step 1: I have a try at inserting manually one row into TRANSLATION table, more referencing on the enclosed example.

Step 2: I started-up on tomcat again. Checking the Translation of [680]. I saw that the list of Locale where showed two locales (one is “en_GB” default, the left one is “zh_CN” that I made in step 1). (See the picture No.1)

Step 3: I clicked on to choose “zh_CN” locale but none of its property could be loaded (See the picture No.2)

Step 4: I set the new values for each field and then save them again. It’s successful.

Step 5: Checked the current database. It’s really strange (See the picture No.3)

Step 6: Checked Translation table’s details ***(See the picture No.4)***. We could recognize that four attributes: objectClass, objectId, locale, objectProperty as a primary key.

So, is this a bug in Postgresql database or from TRANSLATION module?

**Review the issue which I mentioned in “TRANSLATION PROBLEM” email.

Why don’t we use the locales of the User Setting instead of locale database for TRANSLATION module ???**


Hieu.HISPVietnam
Good Health !


Hieu.HISPVietnam
Good Health !