openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <ilgro...@apache.org>
Subject Re: Unexpected 'right truncation' issue
Date Wed, 27 Apr 2016 07:24:22 GMT
Hi Sergey,
I have created a (kind of) nailed-down version of your application at

https://github.com/ilgrosso/cxf-openjpa-poc

Essentially, I have grabbed few classes from CXF's 
cxf-rt-rs-security-oauth2 and injected in my own OpenJPA template 
project: as you can see, this imply using Spring and build-time enhancement.

When you run 'mvn -Psqlgen' on it, you will get the full SQL schema 
under target/database.sql

When you run 'mvn clean test' on it, you will get

https://github.com/ilgrosso/cxf-openjpa-poc/blob/master/src/test/java/net/tirasa/ilgrosso/cxfopenjpapoc/entity/BaseTest.java

executed, where I have grabbed some methods from CXF's 
JPAOAuthDataProviderTest

As you can see, at the moment the only test case available works fine: 
please add another one which shows the problem you are experiencing, thanks.

Regards.

On 26/04/2016 17:33, Sergey Beryozkin wrote:
> Hi Francesco, thanks, so this is what I get.
>
> I see Client references being removed first from various tables (Client
> has @ElementCollection Lists of String for properties like 
> allowedGrantTypes, etc):
>
> 31896  testUnitOpenJPA  TRACE  [http-bio-50025-exec-5] 
> openjpa.jdbc.SQL - <t 593160440, conn 570232632> executing prepstmnt 
> 969065640
> DELETE FROM Client_allowedGrantTypes WHERE CLIENT_CLIENTID = ?
> [params=?]
> ......
> omitting few ones...
> 31897  testUnitOpenJPA  TRACE  [http-bio-50025-exec-5] 
> openjpa.jdbc.SQL - <t 593160440, conn 570232632> executing prepstmnt 
> 583592238
> DELETE FROM Client_registeredAudiences WHERE CLIENT_CLIENTID = ?
> [params=?]
>
> *And Finally* DELETE from the Client table itself, which triggers that 
> INSERT:
>
>
> 31898  testUnitOpenJPA  TRACE  [http-bio-50025-exec-5] 
> openjpa.jdbc.SQL - <t 593160440, conn 570232632> executing prepstmnt 
> 2036246172
> DELETE FROM Client
>     WHERE clientId = ?
> [params=?]
> 31898  testUnitOpenJPA  TRACE  [http-bio-50025-exec-5] 
> openjpa.jdbc.SQL - <t 593160440, conn 570232632> executing prepstmnt 
> 890014212
> INSERT INTO BearerAccessToken_parameters (BEARERACCESSTOKEN_TOKENKEY,
>         propName, value)
>     VALUES (?, ?, ?)
> [params=?, ?, ?]
>
> I can't explain in, as I said I can only think that the fact there's a 
> Many to One relationship from AccessToken to Client causes an 
> auto-refresh of BearerAccessToken & related tables...
>
> I will experiment with moving few properties around...
>
> Cheers, Sergey
>
>
> On 26/04/16 12:22, Francesco Chicchiriccò wrote:
>> On 26/04/2016 11:44, Sergey Beryozkin wrote:
>>> Hi All
>>>
>>> This is my first post to the list, I've tried to solve the issue
>>> myself by checking StackOverflow, etc. I thought I'd give it a try at
>>> OpenJPA users list, given that I do work with OpenJPA 2.4.0.
>>>
>>> I have the following class hierarchy (listing the most relevant 
>>> details):
>>>
>>> @Entity
>>> public class Client {
>>>    private String clientId;
>>> }
>>>
>>>
>>> @Entity
>>> public class BearerAccessToken extends ServerAccessToken {
>>> }
>>>
>>> @MappedSuperclass
>>> public abstract class ServerAccessToken extends AccessToken {
>>>
>>> @ManyToOne
>>> private Client client;
>>> }
>>>
>>> @MappedSuperclass
>>> public abstract class AccessToken {
>>>
>>> @Id
>>> String tokenKey;
>>>
>>> @ElementCollection
>>> @MapKeyColumn(name="propName")
>>> private Map<String, String> parameters = new LinkedHashMap<String,
>>> String>();
>>> }
>>>
>>>
>>> Now, after initializing the DB as follows:
>>>
>>> - Create Client instance (ex, "Client1"), add it to DB:
>>>   Client c1 = new Client("Client1"); // and save
>>> - Create another Client instance (ex, "Client2"), add it to DB:
>>>   Client c2 = new Client("Client2"); // and save
>>> - add a new BearerAccessToken associated with Client2 to DB:
>>>   BearerAccessToken at = new BearerAccessToken();
>>>   at.setClient(c2); // and save
>>>
>>> (Note no tokens are associated with Client1)
>>>
>>> the following sequence works OK:
>>>
>>> 1. delete Client2 (c2)
>>> 2. delete Client1 (c1)
>>>
>>> This is OK, but if I start from deleting Client1 (the one with no
>>> tokens) I immediately see:
>>>
>>> Caused by: <openjpa-2.4.0-r422266:1674604 fatal general error>
>>> org.apache.openjpa.persistence.PersistenceException: data exception:
>>> string data, right truncation;  table: BEARERACCESSTOKEN_PARAMETERS
>>> column: VALUE {prepstmnt 453026232 INSERT INTO
>>> BearerAccessToken_parameters (BEARERACCESSTOKEN_TOKENKEY, propName,
>>> value) VALUES (?, ?, ?)} [code=3401, state=22001]
>>>     at
>>> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:5001). 
>>>
>>>
>>>
>>> I honestly do not know where to start looking. I've seen plenty of
>>> StackOverflow messages about the "string data, right truncation", in
>>> this case AccessToken.parameters map is never touched by my code, it
>>> is empty. And the most confusing thing why this is even happening when
>>> I delete a Client with no tokens associated with it.
>>>
>>> I suspect when the Client is deleted, given a Many to One relationship
>>> from ServerAccessToken to Client (but no OneToMany from Client to
>>> ServerAccessToken), the mapping table gets refreshed in order to find
>>> any tokens which may be linking to Client being deleted). But that is
>>> as far as I can get.
>>>
>>> Can someone please suggest why the above might be occurring, is it a
>>> mapping issue, or possibly OpenJPA issue ?
>>
>> Hi Sergey,
>> I'd start by trying to understand exactly which SQL statement generates
>> the error above, so adding
>>
>> <property name="openjpa.Log" value="SQL=TRACE"/>
>> <property name="openjpa.ConnectionFactoryProperties"
>>      value="PrettyPrint=true, PrettyPrintLineLength=72"/>
>>
>> to your persistence.xml and trying again.
>>
>> HTH
>> Regards.
>>
>
>


-- 
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF committer
http://home.apache.org/~ilgrosso/



Mime
View raw message