Primary keys must not contain null [message #815419] |
Wed, 07 March 2012 11:29  |
Eclipse User |
|
|
|
We have upgraded Glassfish from 3.1.1 to 3.1.2, so also to eclipseLink 3.1.2.
After upgrade, every nativeQuery stopped working with following exception:
Exception [EclipseLink-6044] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.QueryException
Exception Description: The primary key read from the row [ArrayRecord(
=> 1129
=> 2011-09-05 12:50:28.735459)] during the execution of the query was detected to be null. Primary keys must not contain null.
Query: ReadAllQuery(referenceClass=Wowzalog sql="select logid, created from wowzalog l where xtime >= '2011-05-01'::date and xtime < '2012-03-07'::date + 1 and username = 'bulbTest5' order by xtime, logid ASC offset 0 limit 20")
Exception [EclipseLink-6044] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.QueryException
Exception Description: The primary key read from the row [ArrayRecord(
=> 61)] during the execution of the query was detected to be null. Primary keys must not contain null.
Query: ReadAllQuery(referenceClass=Broj sql="select count(1) as broj from wowzalog where xtime >= '2011-05-01'::date and xtime < '2012-03-07'::date + 1 and username = 'bulbTest5'")
Is there any reason why this native queries stopped working?
Is there any workaround?
Is this a bug in EclipseLink?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Primary keys must not contain null [message #817092 is a reply to message #816777] |
Fri, 09 March 2012 11:19   |
Eclipse User |
|
|
|
I am unsure why this would have worked in a prior version, since the "eclipselink.jpa.uppercase-column-names" was added to resolve the issue that kept cropping up.
The issue (also described in bug 299926) was mostly with native queries that return entities, as when EclipseLink generates JPQL queries it knows the position of each field and so does not need to use the field to look up the value. This is why NamedQuery and createQuery api will work regardless of the database or field names defined in the mappings.
Native queries that return/build entities though must use the field name string as it is defined in the mapping to search for the value returned. The problem is that users had/have the tendency to define their fields using lower or mixed case, and on other fields let the default be used which is uppercase. So while selects still work due to most databases being case insensitive by default, the string they return for the column name isn't. There is no way to look up "ID" using "id" on a hashmap/table structure. And different databases return the column name differently - Oracle always returns them in uppercase, while others may return them as lower (assuming they are not delimited).
EclipseLink early on had the "eclipselink.jdbc.uppercase-column-names" flag, which would take the resultsets and uppercase the column names. This worked in a lot of cases, but required that users define the mappings using the uppercase field name. So it would not help if you used @Column(name="idscm_to_kasa").
"eclipselink.jpa.uppercase-column-names" was added (bug 299926) to uppercase both the field name used for searches, and set the "eclipselink.jdbc.uppercase-column-names" so that both sides would be uppercase so that using a hashmap would work.
That said, EclipseLink 2.3 should honor the column annotation 100% of the time in all versions. The only thing I can think of is you set the eclipselink.jdbc.uppercase-column-names which would cause the id field to be returned as "IDSCM_TO_KASA" instead of the "idscm_to_kasa" that is expected for the native query, and not have had this flag set when using a prior version.
Mising name - your fields are defined in lower case, but your query uses select *, so it is at the mercy of what the database returns. If you are using Oracle for instance, it will always return the field names in upper case (unless they are delimited), while others might return them in lower case. Check what database you are using and what it returns.
Can you also get the exact version and build number for the EclipseLink version in gf 3.1.1 you are using? This can be done by setting the logging property to log at FINEST, which will print the version at login. With this I can try checking what might have changed to affect the issue, such as if the flag was set to true by default in the particular build used.
Bug 294267 exists to have this default changed from false to true - please vote for it.
|
|
|
|
|
|
|
Re: Primary keys must not contain null [message #879727 is a reply to message #879131] |
Thu, 31 May 2012 14:23   |
Eclipse User |
|
|
|
Setting the eclipselink.jpa.uppercase-column-names property to true is the solution if the case the fields are defined in does not match the case the database returns them in.
I have not seen a bug filed to investigate why something that worked in 2.2.1 doesn't in 2.3.2, and I have not been able to reproduce the issue locally. I would recommend you file a bug with particular details like:
a) particular build used. This should show up in the EclipseLink exception and logs with logging turned on.
b) The entity and field names used
c) The query itself, and the results returned when it is not returning an entity
d) What the database returns for the metadata. This can be done using DatabaseAccessor getTableInfo(String catalog, String schema, String tableName, String[] types) if you want. Something like:
print(((JpaEntityManager)em.getDelegate()).getSession().getAccessor().getTableInfo(null, null, "tableName", null, ((JpaEntityManager)em.getDelegate()).getSession()))
e) the properties contained in ((JpaEntityManager)em.getDelegate()).getProperties();
f) the results of the above on both versions.
|
|
|
Re: Primary keys must not contain null [message #885235 is a reply to message #879727] |
Tue, 12 June 2012 12:47  |
Eclipse User |
|
|
|
I am new to JPA. Am using NetBeans 7.1.2 and Jave EE 6. JPA using Eclipselink and Glassfish (3.1.2) are provided by those tools. This problem with case on database column names is happening with MySQL database under Windows 7.
Replacing the 3.1.2 glassfish/modules/org.exlipse.persistence.* components with those components from 3.1.1 resolved the issue.
[Updated on: Tue, 12 June 2012 14:01] by Moderator
|
|
|
Powered by
FUDForum. Page generated in 0.04756 seconds