Hello dear Cuba Team,
since upgrade from 7.0.1 to 7.0.3 we got following error while initializing application: The attribute [id] of class [ExtUser] is mapped to a primary key column in the database. Updates are not allowed.
Please see attached log file.
error.log (10,5 KB)
Hi Mike,
Could you provide a test project?
Or at least source code of your ExtUser entity.
HI Konstantin,
here are the code of class ExtUser and sample project (sample.zip (182,9 KB)
) to reproduce the issue:
package com.company.sample.entity;
import com.haulmont.cuba.core.entity.annotation.Extends;
import com.haulmont.cuba.security.entity.User;
import javax.persistence.Entity;
import javax.persistence.JoinColumn;
import javax.persistence.JoinTable;
import javax.persistence.ManyToMany;
import java.util.List;
@Entity(name = "sample$ExtUser")
@Extends(User.class)
public class ExtUser extends User {
@JoinTable(name = "USER_STORE_LINK",
joinColumns = @JoinColumn(name = "USER_ID"),
inverseJoinColumns = @JoinColumn(name = "STORE_ID"))
@ManyToMany(mappedBy = "")
protected List<Store> stores;
public List<Store> getStores() {
return stores;
}
public void setStores(List<Store> stores) {
this.stores = stores;
}
}Hi Mike,
The sample project starts fine if you fix the last update in 10.create-db.sql as follows:
update SEC_USER set DTYPE = 'sample_ExtUser' where DTYPE is null ^
The point is to have all existing User records updated with the extended type. In your project it was sec$User for some reason, so the app couldn’t find any users. However, the error was different - about inability to load anonymous user.
Hi Konstantin,
thx, the sample project was just a simple representation of our project here.
I saw in our real project ‘sample$ExtUser’ instead of ‘sample_ExtUser’ was used, therefore I changed each occurrence as you mentioned ‘sample_ExtUser’ but we get still the same exception while starting the application:
2019-04-08 00:45:56.401 'ERROR [main] com.haulmont.cuba.core.sys.AbstractWebAppContextLoader - Error initializing application
javax.persistence.PersistenceException: Exception [EclipseLink-7251] (Eclipse Persistence Services - 2.7.3.2-cuba): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The attribute [id] of class [....entity.ExtUser] is mapped to a primary key column in the database. Updates are not allowed.'
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:979) ~[org.eclipse.persistence.jpa-2.7.3-2-cuba.jar:na]
at com.haulmont.cuba.core.sys.persistence.PersistenceImplSupport$ContainerResourceSynchronization.detachAll(PersistenceImplSupport.java:496) ~[cuba-core-7.0.3.jar:7.0.3]
at com.haulmont.cuba.core.sys.persistence.PersistenceImplSupport$ContainerResourceSynchronization.beforeCommit(PersistenceImplSupport.java:449) ~[cuba-core-7.0.3.jar:7.0.3]
at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerBeforeCommit(TransactionSynchronizationUtils.java:96) ~[spring-tx-5.1.2.RELEASE.jar:5.1.2.RELEASE]
at org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerBeforeCommit(AbstractPlatformTransactionManager.java:922) ~[spring-tx-5.1.2.RELEASE.jar:5.1.2.RELEASE]
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:730) ~[spring-tx-5.1.2.RELEASE.jar:5.1.2.RELEASE]
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:714) ~[spring-tx-5.1.2.RELEASE.jar:5.1.2.RELEASE]
at com.haulmont.cuba.core.sys.TransactionImpl.commit(TransactionImpl.java:104) ~[cuba-core-7.0.3.jar:7.0.3]
at com.haulmont.cuba.security.auth.AuthenticationManagerBean.login(AuthenticationManagerBean.java:119) ~[cuba-core-7.0.3.jar:7.0.3]
at com.haulmont.cuba.security.auth.AnonymousSessionHolder.loginAnonymous(AnonymousSessionHolder.java:82) ~[cuba-core-7.0.3.jar:7.0.3]
at com.haulmont.cuba.security.auth.AnonymousSessionHolder.initializeAnonymousSession(AnonymousSessionHolder.java:72) ~[cuba-core-7.0.3.jar:7.0.3]
at com.haulmont.cuba.security.auth.AnonymousSessionHolder.applicationStarted(AnonymousSessionHolder.java:45) ~[cuba-core-7.0.3.jar:7.0.3]
at com.haulmont.cuba.core.sys.AppContext.startContext(AppContext.java:239) ~[cuba-global-7.0.3.jar:7.0.3]
at com.haulmont.cuba.core.sys.AppContext$Internals.startContext(AppContext.java:302) ~[cuba-global-7.0.3.jar:7.0.3]
at com.haulmont.cuba.core.sys.AbstractWebAppContextLoader.contextInitialized(AbstractWebAppContextLoader.java:86) ~[cuba-global-7.0.3.jar:7.0.3]
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4663) [catalina.jar:9.0.14]
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5131) [catalina.jar:9.0.14]
I’ve been debugged the issue and I saw that the container was able to load the anonymous user:
The exception happens after successful login at: com/haulmont/cuba/security/auth/AuthenticationManagerBean.java:119
because of a change of the of the user entity in attribute id:
The issue occurs when we change from version 7.0.2 to 7.0.3, was there a related change in platform?
Hi Mike,
I will be happy to help if you provide a reproducible test.
If you can’t, try to set a field breakpoint and trace what is changing id:
Hi Konstatin,
I found the following sequence during the debug session with your suggested breakpoint:
object creation with /com/haulmont/cuba/core/entity/BaseUuidEntity.java:45
1. id=c8b4aa18-3517-31c5-7676-f7248b144c38
2. id=cb909afd-6448-ae20-5794-e6f786d0232b
load from database and transfer to object via com.haulmont.cuba.core.entity.BaseUuidEntity#_persistence_set
3. id=a405db59-e674-4f63-8afe-269dda788fe8
uow : clone for change set recognition via org.eclipse.persistence.descriptors.copying.InstantiationCopyPolicy#buildClone
/com/haulmont/cuba/core/entity/BaseUuidEntity.java:45
4. id=5083ed7e-89df-bd52-e03d-8e718cd51a8c
it leads then into the following change set:
changeRecord = {DirectToFieldChangeRecord@12066} "org.eclipse.persistence.internal.sessions.DirectToFieldChangeRecord(id)"
newValue = {UUID@11463} "a405db59-e674-4f63-8afe-269dda788fe8"
oldValue = {UUID@11858} "5083ed7e-89df-bd52-e03d-8e718cd51a8c"
attribute = "id"
mapping = {DirectToFieldMapping@12063} "org.eclipse.persistence.mappings.DirectToFieldMapping[id-->SEC_USER.ID]"
owner = {ObjectChangeSet@12090} "ObjectChangeSet(694653057, ....ExtUser)[org.eclipse.persistence.internal.sessions.DirectToFieldChangeRecord(id), org.eclipse.persistence.internal.sessions.DirectToFieldChangeRecord(changePasswordAtNextLogon), org.eclipse.persistence.internal.sessions.DirectToFieldChangeRecord(createTs), org.eclipse.persistence.internal.sessions.DirectToFieldChangeRecord(login), org.eclipse.persistence.internal.sessions.DirectToFieldChangeRecord(loginLowerCase), org.eclipse.persistence.internal.sessions.DirectToFieldChangeRecord(name), org.eclipse.persistence.internal.sessions.DirectToFieldChangeRecord(updateTs), org.eclipse.persistence.internal.sessions.DirectToFieldChangeRecord(updatedBy), org.eclipse.persistence.internal.sessions.DirectToFieldChangeRecord(version)]"
I guess that the wrong CopyPolicy is choosen or the merge does not work properly, instead of InstantiationCopyPolicy I would expect PersistenceEntityCopyPolicy, therefore I tried to use @CopyPolicy just to see if clone logic will change, and it does but in the end it fails due to missing PropertyChangeSupport in the isDirty validation.
I‘ve my doubts that the current clone implementation is correct, I would like to see a constructor based approach without an artificial id assignment at the beginning
Hi,
7.0.3 version doesn’t contain any changes related to the persistence.
Perhaps, it is a problem with entity enhancing. Try to decompile ExtUser class and check that:
PersistenceWeaved, PersistenceObject, PersistenceWeavedFetchGroups, PersistenceWeavedChangeTracking, CubaEnhanced interfaces._persistence_post_clone, _persistence_new, _persistence_get, _persistence_set, _persistence_get_stores, _persistence_set_stores.I tried to reproduce error on the test project, but it works. testextends.zip (79.7 KB)
Could you check that the test project works for you (without errors)?
Hello Andrey,
thx, therefore I raised the issue before here.
I will check your suggestions and inform you.
After I switched to the latest version of the studio cuba-studio-2018.3-9.0 the problem does not occur anymore.
I am very unhappy about not knowing the reason but I am very happy to have no problem anymore. 
Thx for everyone, I will close the issue now.
We are going to introduce some startup-time checks to fail fast in case of some entities are not enhanced properly. Hope it will help in the future.