Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Subject: Re: Unexpected 'right truncation' issue
To: users@openjpa.apache.org
References: <571F387F.50906@gmail.com> <571F4F7F.40803@apache.org>
 <571F8A2D.70500@gmail.com> <57206926.3070504@apache.org>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <572088BD.4080601@gmail.com>
Date: Wed, 27 Apr 2016 10:39:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <57206926.3070504@apache.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Francesco

many thanks, I'm sorry for involving you into this project :-), but it 
is much appreciated you trying to help. I also hope my query is not off 
topic for this list - as there might be some OpenJPA issue hiding there
(though the high chance is it is the way I misconfigured JPA mappings 
that causes it).

I've experimented for few days by trying to emulate this issue locally 
in CXF JPAOAuthDataProviderTest/JPACodeDataProviderTest, but could not.
Perhaps your project will make it easier as it is closer to the real 
deployment case.

FYI, this test fails:

https://github.com/apache/cxf-fediz/blob/master/systests/oidc/src/test/java/org/apache/cxf/fediz/systests/oidc/OIDCTest.java#L412

This test preloads a packaged Fediz OIDC war and sends actions to it 
remotely.

Disabling all other tests and running only this test does the following 
(which is what I described earlier) :
- create client1 and client2, get a code for Client 2 and exchange for a 
token (i.e BearerAccessToken with a link to Client2 is saved), finally 
start deleting clients starting from Client 1 and it fails
(DELETE triggers an insert)

This is reproducible against the embedded Tomcat and a standalone Tomcat 
though when I try to repeat the same sequence manually it is all OK.

So I will spend some time on trying to narrow it down further. and 
update you and what I have found.

Many thanks for trying to help and sorry in advance for the noise (when 
I report later it proved to be the misconfiguration :-))

Sergey


On 27/04/16 08:24, Francesco Chicchiriccò wrote:
> 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.
>>>
>>
>>
>
>