openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Unexpected 'right truncation' issue
Date Wed, 27 Apr 2016 16:25:52 GMT
I haven't made any progress today so I'll do something else for the next 
few days to make me feel I can still do something and then return to 
this issue :-)

Thanks, Sergey
On 27/04/16 10:39, Sergey Beryozkin wrote:
> 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.
>>>>
>>>
>>>
>>
>>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Mime
View raw message