I am experiencing an issue where I am unable to save an entity with the following error:
IllegalStateException: An attempt to save an entity with reference to some not persisted entity. All newly created entities must be saved in the same transaction. Put all these objects to the CommitContext before commit.
The model is a main entity (customer) with a composition field (compliance) and then that composition field has a further composition field (compliance action). When a new compliance entity is created under a customer and a compliance action is added to the non-committed compliance issue then I experience the illegalStateException.
I have looked through several topics on the forum but am struggling to understand how the problem in this particular case can be resolved. It is a simple project with no custom code. It just has:
Customer Screen - an EntityCombined Screen built directly using cuba create screen from the entity model
Compliance Screen - an Edit screen built directly using cuba create screen from the entity model
Compliance Action Screen - an Edit screen built directly using cuba create screen from the entity model
I’ve attached an example project that the above description is based on. compliancetest.zip (455.1 KB)
To reproduce:
1 add a customer
2 add a new compliance
3 add a new compliance action
4 save compliance
Any help or suggestions to resolve the issue would be appreciated.
Thanks
David
Thanks for the reporting the case and for submitting the example. We’ll have a look at the cause of this behaviour. At the moment you can use a workaround - save parent records before adding child ones. It is not very convenient, but it works.
I’d advise you to use CUBA 7 API (data containers, loaders, and data context) rather than outdated datasources. Also, EntityCombinedScreen is deprecated, please use the master-detail screen instead.
The cause of the issue was the outdated API, I’ve reimplemented the sample app using CUBA 7, please find it attached.compliancetest.zip (96.9 KB)
Thanks for the update. I note that this is an issue with legacy screens and as we continue to build our application we will be developing using the newer api.
However, we already have a significant application that has been in development in Cuba for a number of years and therefore we currently have extensive use of the legacy screens. As our application is pretty complicated the transition of these into the new api is not going to be a simple task or quick task. With this in mind is there a solution to support the legacy api in the interim? We are happy to invoke custom code etc to get it working but we are struggling to understand how to even approach it.
Just keep old screens as is. We are not planning to remove legacy API from the future CUBA 7.x versions. Is the sample contains the existing screens that suddenly stopped working?
In CUBA 6.x was a limitation - it supported only two levels of nesting, and I’m afraid this limitation stayed in CUBA 7.x when you use the legacy API. In your example you have three levels. Hope this documentation will help: One-to-Many: Three Levels of Nesting - CUBA Platform. Developer’s Manual
Thanks for your email. On reviewing the link you sent and a bit of head scratching, the penny finally dropped. The data model data structure was correct and I had nested compositions within the limits advised in link. The issue was related to the correct data structure within the screens themselves. I missed that the nested compositions structure must be replicated from the main parent screen even though the complianceAction is not directly used in the customer screen. ie the customer screen must have all the nested datasources 2 levels deep. customerDs with nested datasource complianceDs with nested datasource complianceActionDs
