When an entity is added to a nested datasource--unique constraint violation when parentDs is updated

Hi dear Cubans,

I’m facing a problem, I cannot figure a way out of it and I kindly ask you for support.

I have a several nested datasources that handle a couple of entities from a couple of related tables (please check attached datasources-definition.png’ picture).

I generated a mixed browse-edit screen in Cuba editor for the “Person” entity. By default “personDs” and “personsDs” were created. I created manually all the nested datasources that can be seen in the picture. Please also check the attached pictures ‘person-table.png’ and ‘contact-table.png’ in order to understand the model.

The problem appears when adding a phone number to an existing person.

How I initialize the datasources
All I do in the ItemChangeListener of “personsDs” is call


and then load the reloadedItem” 's properties in some frames.

How I update the “phoneNumberListDs”
So after creating the new “PhoneNumber” object I’m inserting it into “phoneNumberListDs” datasource like this:

Person editedItem = personDs.getItem();

Collection<PhoneNumber> phoneNumberCollection = phoneNumberFrameBox.getPhoneNumbersDs().getItems();
List<PhoneNumber> phoneNumberList = editedItem.getContact().getContactDetailList().get(0).getPhoneNumberList();
// .get(0) because for now the project decided to have only one ContactDetail in the list 
for(PhoneNumber entity : phoneNumberCollection)

After doing so “personDs”, “contactDs”, “contactDetailListDs” and “phoneNumberListDs” datasources change their “modified” attribute to true, “phoneNumberListDs” has 1 item to create and the others have 1 item to update each while “postalAddressDs” remains untouched. Please check attached ‘personDs.png’, ‘contactDs.png’, etc in order to see the state of the datasources in debug mode right before triggering the commit.

When I try to edit an existent entry and add another phone number unique constrain violation occurs. Please check ‘exception.txt’ file in order to see all the causes from within the exception object. The error appears while handling “Contact” table, the weird thing is that the framework uses “insert” method when trying to update the “Contact” entity instead of “update”. This info is available in the exception.txt’ file.

The support would be really appreciated,









exception.txt (2.5K)

Hi Andrei,

CUBA support only two levels of composition, and I see three levels in your screen. It can be the cause of the problem.

Please check out this guide: Composite Structures

If it doesn’t help and you are sure you do everything according to the documentation, please create a small test project and attach it here along with a description how to reproduce the issue.

Hi Konstantin,

Thank you for your answer.

I checked the documentation and indeed I had 3 levels of composition. I created a small test project in which I followed the procedure from documentation meaning that I’ve split the datasources so I’ll only have 2 levels of composition.

In order to run the test you should click on the Application -> Persons -> Create. Here please fill every field (even if they are not mandatory), click on the Create button from the right part of the screen in order to add a phone number (fill the values, click Ok), click Ok. Here at commit is the problem.

Thank you kindly,

four-levels-of-composition.7z (101.0K)

Looking at the data model and at the datasources structure, I see at least one mistake: you should use nested datasources for composition and standalone (with query) for associations. But it’s not true for your Contact - ContactDetails link.

Meaning like in the attached picture? If yes then I’ve modified the project and I have the same behavior.

May I ask you to point the other mistakes?



four-levels-of-composition.7z (101.1K)

Are you sure you want to use the combined screen here? If yes, please cleanup and comment your code, otherwise it’s too difficult to distinguish what is generated by Studio from what is added by you.
Also, please use zipProject Gradle task to archive the project.

Yes, the task asks for the combined screen.
I’ve commented the code to mark my parts, you’ll see in PersonBrowse.java:

// custom code from HERE
// ***
  <<< some code >>>
// ***
// until HERE

PhoneNumberFrame and PostalAddressFrame contents are all custom.
I’ve attached the project archived with zipProject Gradle.

four-levels-of-composition.zip (45.8K)

Hi Andrei,

I’ve managed to make your screen work, see my comments in the attached project.

Most of your custom code has gone, along with ‘cascade = CascadeType.PERSIST’ in the data model. Never use cascading on the JPA level when using CUBA compositions.

Let me know if something doesn’t work for you.

BTW, we are going to implement a new alternative UI data layer in the platform version 7, so such non-standard data management in UI will be much more straightforward in the future.

four-levels-of-composition.zip (46.2K)

1 Like

Hi Konstantin,
Sorry for coming back so late.
Everything worked well after applying what you showed me in the sample project. Now I better understand how to work with datasources.
Good to hear that in the platform version 7 these things will be much more straightforward.
Thank you very much for your help,