jpox-issues — JPOX issues, bugs, features, roadmap

[Jpox-issues] [JPOX JIRA] Commented: (NUCCORE-361) Unexpected flush for 1-to-1 + dependent="true" with optimistic lock

[Andy J. (JIRA) <web...@jp...>]

    [ http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16956#action_16956 ] 

Andy Jefferson commented on NUCCORE-361:
----------------------------------------

Whether a test appears in test.jdo.datastore and test.jdo.application is of no relevance. A test scenario is to be run on its own. In that particular case, one tests Dependent fields for datastore id, and one for Application id. They are separate tests (different samples used) even though the JUnit code is the same.

Having a separate M2 project means that M2 project is to be run ... on its own ... separately. We don't use any aggregator project for running tests; that is a superclass for inheritance only.

> Unexpected flush for 1-to-1 + dependent="true" with optimistic lock 
> --------------------------------------------------------------------
>
>                 Key: NUCCORE-361
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361
>             Project: DataNucleus Core
>          Issue Type: Bug
>          Components: JDO
>    Affects Versions: 1.1.5, 2.0.0.m1
>            Reporter: Renato Garcia
>         Attachments: DependentFieldTest-patch.txt, patch.txt, TCK-after.zip, TCK-before.zip, test-result.zip, testrun.out.zip, unit-test-result.zip
>
>
> A flush during causes problem to optimistic lock. See fourm details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Commented: (NUCCORE-361) Unexpected flush for 1-to-1 + dependent="true" with optimistic lock

[Renato G. (JIRA) <web...@jp...>]

    [ http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955#action_16955 ] 

Renato Garcia commented on NUCCORE-361:
---------------------------------------

Andy,
I would like a little help in order to understand better the test project structure... I've noticed that for some files/test, they appear into different projects, even thought they are identical. Are they links? Should they be considered the same? I already took a look at http://www.datanucleus.org/development/test/unittests.html, but I could not find anything about this. 
i.e. DependentFieldTest appears into test.jdo.datastore and test.jdo.application, and they are identical.

Tks!

> Unexpected flush for 1-to-1 + dependent="true" with optimistic lock 
> --------------------------------------------------------------------
>
>                 Key: NUCCORE-361
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361
>             Project: DataNucleus Core
>          Issue Type: Bug
>          Components: JDO
>    Affects Versions: 1.1.5, 2.0.0.m1
>            Reporter: Renato Garcia
>         Attachments: DependentFieldTest-patch.txt, patch.txt, TCK-after.zip, TCK-before.zip, test-result.zip, testrun.out.zip, unit-test-result.zip
>
>
> A flush during causes problem to optimistic lock. See fourm details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Updated: (NUCCORE-361) Unexpected flush for 1-to-1 + dependent="true" with optimistic lock

[Renato G. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Renato Garcia updated NUCCORE-361:
----------------------------------

    Attachment: test-result.zip

Test result after patches applied.

> Unexpected flush for 1-to-1 + dependent="true" with optimistic lock 
> --------------------------------------------------------------------
>
>                 Key: NUCCORE-361
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361
>             Project: DataNucleus Core
>          Issue Type: Bug
>          Components: JDO
>    Affects Versions: 1.1.5, 2.0.0.m1
>            Reporter: Renato Garcia
>         Attachments: DependentFieldTest-patch.txt, patch.txt, TCK-after.zip, TCK-before.zip, test-result.zip, testrun.out.zip, unit-test-result.zip
>
>
> A flush during causes problem to optimistic lock. See fourm details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Updated: (NUCCORE-361) Unexpected flush for 1-to-1 + dependent="true" with optimistic lock

[Renato G. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Renato Garcia updated NUCCORE-361:
----------------------------------

    Attachment: testrun.out.zip

Build output for run_tests.sh

> Unexpected flush for 1-to-1 + dependent="true" with optimistic lock 
> --------------------------------------------------------------------
>
>                 Key: NUCCORE-361
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361
>             Project: DataNucleus Core
>          Issue Type: Bug
>          Components: JDO
>    Affects Versions: 1.1.5, 2.0.0.m1
>            Reporter: Renato Garcia
>         Attachments: DependentFieldTest-patch.txt, patch.txt, TCK-after.zip, TCK-before.zip, test-result.zip, testrun.out.zip, unit-test-result.zip
>
>
> A flush during causes problem to optimistic lock. See fourm details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Commented: (NUCCORE-361) Unexpected flush for 1-to-1 + dependent="true" with optimistic lock

[Renato G. (JIRA) <web...@jp...>]

    [ http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16951#action_16951 ] 

Renato Garcia commented on NUCCORE-361:
---------------------------------------

1 - Testcase for "Transient instances cant be deleted"
I've included a new test scenario testNullifyNonPersistent1to1Relation using the existing DependentTestField, which reproduces the problem described. (DependentFieldTest-patch.txt)

2 - Unit Test
I ran a "mvn clean test" for the aggregator project test.maven2.parent(This is probably the "strange way" ;) Didn't know about the run_tests.sh script). I've noticed that ApplicationIdentityTest will fail using this "aggregator approach" with a "Unique constraint violation", probably other stuff won't work either.

So, I found the run_tests.sh script,  and I've ran the tests again using it.
The NEW results(test-result.zip) are attached along with the build output(testrun.out.zip). It already includes the new scenario above.

Please, could you check if they look alright now?(There are errors yet, but I assume they are already known). 

3 - TCK
I'm still trying to figure it out what I did wrong. I've run the tests using the 2.3-ea branch, I had to modify the project.xml to point to 2.0.0-SNAPSHOT version and force the "eb" version into the repo, by replacing jdo2-api-2.3-ea.jar. 

> Unexpected flush for 1-to-1 + dependent="true" with optimistic lock 
> --------------------------------------------------------------------
>
>                 Key: NUCCORE-361
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361
>             Project: DataNucleus Core
>          Issue Type: Bug
>          Components: JDO
>    Affects Versions: 1.1.5, 2.0.0.m1
>            Reporter: Renato Garcia
>         Attachments: DependentFieldTest-patch.txt, patch.txt, TCK-after.zip, TCK-before.zip, unit-test-result.zip
>
>
> A flush during causes problem to optimistic lock. See fourm details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Updated: (NUCCORE-361) Unexpected flush for 1-to-1 + dependent="true" with optimistic lock

[Renato G. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Renato Garcia updated NUCCORE-361:
----------------------------------

    Attachment: DependentFieldTest-patch.txt

New scenario included

> Unexpected flush for 1-to-1 + dependent="true" with optimistic lock 
> --------------------------------------------------------------------
>
>                 Key: NUCCORE-361
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361
>             Project: DataNucleus Core
>          Issue Type: Bug
>          Components: JDO
>    Affects Versions: 1.1.5, 2.0.0.m1
>            Reporter: Renato Garcia
>         Attachments: DependentFieldTest-patch.txt, patch.txt, TCK-after.zip, TCK-before.zip, unit-test-result.zip
>
>
> A flush during causes problem to optimistic lock. See fourm details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Reopened: (NUCRDBMS-243) JDOQL2 : Cater for queries of the form "SELECT this ..."

[Andy J. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Jefferson reopened NUCRDBMS-243:
-------------------------------------


> JDOQL2 : Cater for queries of the form "SELECT this ..."
> --------------------------------------------------------
>
>                 Key: NUCRDBMS-243
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-243
>             Project: DataNucleus RDBMS
>          Issue Type: Task
>          Components: Queries
>            Reporter: Andy Jefferson
>            Assignee: Andy Jefferson
>             Fix For: 2.0.0.m2
>
>
> SELECT this FROM ...
> should result in the same query as
> SELECT FROM ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Commented: (NUCRDBMS-245) Select all columns in default fetch group at once when querying subclasses

[Andy J. (JIRA) <web...@jp...>]

    [ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16950#action_16950 ] 

Andy Jefferson commented on NUCRDBMS-245:
-----------------------------------------

I use SVN trunk. I see no issue. JDOQL2 on 1.1 is not developed further

> Select all columns in default fetch group at once when querying subclasses
> --------------------------------------------------------------------------
>
>                 Key: NUCRDBMS-245
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-245
>             Project: DataNucleus RDBMS
>          Issue Type: Improvement
>          Components: Queries
>    Affects Versions: 1.1.5
>         Environment:         Java 1.6.0_13
>         MySQL Connector/J 5.1.7
>         DataNucleus 1.1.5
>            Reporter: Cyril Bouteille
>
> In the testcase attached @ http://www.datanucleus.org/servlet/forum/viewthread_thread,5695 Hotel extends WebContent.
> A simple newQuery(Hotel.class, "this.name == :name") generates a lot of SQL statement which could be optimized.
> 1) selecting THIS.ID first
> FINE: SELECT DISTINCT `THIS`.`ID` FROM `TEST_HOTEL` `THIS` WHERE `THIS`.`NAME` = <'Test'>
> 2) then select discriminator column for each ID in the result set
> FINE: SELECT `A1`.`WCMS_TYPE` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE 1 = `A0`.`ID`
> FINE: SELECT `A1`.`WCMS_TYPE` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE 6 = `A0`.`ID`
> 3) and if you add pm.makeTransientAll(hotelList, true) @ Main:49, it finally selects all the other fields on detach/transient step
> FINE: SELECT `A1`.`WCMS_PATH`,`A0`.`NAME` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE `A1`.`ID` = <1>
> FINE: SELECT `A1`.`WCMS_PATH`,`A0`.`NAME` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE `A1`.`ID` = <6>
> So if x is the # results returned by the query, it generates 1+2x queries.
> We have a lot of queries behaving in a similar way and scalability could be improved if some of all of the statements could be compacted.
> Could the first SELECT get all the columns from TEST_WC and TEST_HOTEL in default fetch group at once in (1)?
> Or at least combine (2) and (3)?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Commented: (NUCRDBMS-245) Select all columns in default fetch group at once when querying subclasses

[Cyril B. (JIRA) <web...@jp...>]

    [ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16949#action_16949 ] 

Cyril Bouteille commented on NUCRDBMS-245:
------------------------------------------

Andy, I tried it with JDOQL2 and I still see the same issue.
I set datanucleus.query.JDOQL.implementation=JDOQL2 and update Main:44 to newQuery("JDOQL2", "SELECT FROM org.datanucleus.test.Hotel WHERE this.name == :name") but it still generates the same number of statements.
Am I missing something?
If not, can we reopen this for DN2.0?


FINE: JDOQL Query : Compiling "SELECT DISTINCT this FROM org.datanucleus.test.Hotel WHERE this.name == :name"
Aug 17, 2009 12:04:13 PM org.datanucleus.store.query.AbstractJDOQLQuery compileInternal
FINE: JDOQL Query : Compile Time = 26 ms
Aug 17, 2009 12:04:13 PM org.datanucleus.store.rdbms.query2.QueryToSQLMapper compile
FINE: QueryCompilation:
  [result:PrimaryExpression{this}]
  [filter:DyadicExpression{PrimaryExpression{this.name}  =  ParameterExpression{name}}]
  [symbols: name type=java.lang.String, this type=org.datanucleus.test.Hotel]
Aug 17, 2009 12:04:13 PM org.datanucleus.store.rdbms.query2.JDOQLQuery2 performExecute
FINE: JDOQL Query : Executing "SELECT DISTINCT this FROM org.datanucleus.test.Hotel WHERE this.name == :name" ...
Aug 17, 2009 12:04:13 PM org.datanucleus.store.query.Query performExecuteTask
FINE: Starting query "SELECT DISTINCT this FROM org.datanucleus.test.Hotel WHERE this.name == :name" in separate thread with timeout of 60,000ms
FINE: SELECT `A0`.`ID` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE `A1`.`WCMS_TYPE` = 'P' AND `A0`.`NAME` = <'Test'>
FINE: SELECT `A1`.`WCMS_TYPE` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE 1 = `A0`.`ID`
FINE: SELECT `A1`.`WCMS_TYPE` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE 6 = `A0`.`ID`
FINE: SELECT `A1`.`WCMS_TYPE` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE 11 = `A0`.`ID`
FINE: SELECT `A1`.`WCMS_TYPE` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE 16 = `A0`.`ID`
Aug 17, 2009 12:04:13 PM org.datanucleus.store.rdbms.query2.JDOQLQuery2 performExecute
FINE: JDOQL Query : Execution Time = 110 ms
Aug 17, 2009 12:04:13 PM org.datanucleus.test.Main main
INFO: Result: 4 items
FINE: SELECT `A1`.`WCMS_PATH`,`A0`.`NAME` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE `A1`.`ID` = <1>
FINE: SELECT `A1`.`WCMS_PATH`,`A0`.`NAME` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE `A1`.`ID` = <6>
FINE: SELECT `A1`.`WCMS_PATH`,`A0`.`NAME` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE `A1`.`ID` = <11>
FINE: SELECT `A1`.`WCMS_PATH`,`A0`.`NAME` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE `A1`.`ID` = <16>


> Select all columns in default fetch group at once when querying subclasses
> --------------------------------------------------------------------------
>
>                 Key: NUCRDBMS-245
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-245
>             Project: DataNucleus RDBMS
>          Issue Type: Improvement
>          Components: Queries
>    Affects Versions: 1.1.5
>         Environment:         Java 1.6.0_13
>         MySQL Connector/J 5.1.7
>         DataNucleus 1.1.5
>            Reporter: Cyril Bouteille
>
> In the testcase attached @ http://www.datanucleus.org/servlet/forum/viewthread_thread,5695 Hotel extends WebContent.
> A simple newQuery(Hotel.class, "this.name == :name") generates a lot of SQL statement which could be optimized.
> 1) selecting THIS.ID first
> FINE: SELECT DISTINCT `THIS`.`ID` FROM `TEST_HOTEL` `THIS` WHERE `THIS`.`NAME` = <'Test'>
> 2) then select discriminator column for each ID in the result set
> FINE: SELECT `A1`.`WCMS_TYPE` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE 1 = `A0`.`ID`
> FINE: SELECT `A1`.`WCMS_TYPE` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE 6 = `A0`.`ID`
> 3) and if you add pm.makeTransientAll(hotelList, true) @ Main:49, it finally selects all the other fields on detach/transient step
> FINE: SELECT `A1`.`WCMS_PATH`,`A0`.`NAME` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE `A1`.`ID` = <1>
> FINE: SELECT `A1`.`WCMS_PATH`,`A0`.`NAME` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE `A1`.`ID` = <6>
> So if x is the # results returned by the query, it generates 1+2x queries.
> We have a lot of queries behaving in a similar way and scalability could be improved if some of all of the statements could be compacted.
> Could the first SELECT get all the columns from TEST_WC and TEST_HOTEL in default fetch group at once in (1)?
> Or at least combine (2) and (3)?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Created: (NUCCORE-364) Add persistence property giving control over localisation language rather than accepting default JRE

[Andy J. (JIRA) <web...@jp...>]

Add persistence property giving control over localisation language rather than accepting default JRE
----------------------------------------------------------------------------------------------------

                 Key: NUCCORE-364
                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-364
             Project: DataNucleus Core
          Issue Type: Task
          Components: Code Structure
            Reporter: Andy Jefferson
            Assignee: Andy Jefferson
             Fix For: 2.0.0.m2


Add persistence property "datanucleus.localisation.language" to define the language to use. This will apply to all PMFs/EMFs

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Resolved: (NUCCORE-364) Add persistence property giving control over localisation language rather than accepting default JRE

[Andy J. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCCORE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Jefferson resolved NUCCORE-364.
------------------------------------

    Resolution: Fixed

SVN trunk has this

> Add persistence property giving control over localisation language rather than accepting default JRE
> ----------------------------------------------------------------------------------------------------
>
>                 Key: NUCCORE-364
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-364
>             Project: DataNucleus Core
>          Issue Type: Task
>          Components: Code Structure
>            Reporter: Andy Jefferson
>            Assignee: Andy Jefferson
>             Fix For: 2.0.0.m2
>
>
> Add persistence property "datanucleus.localisation.language" to define the language to use. This will apply to all PMFs/EMFs

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Resolved: (NUCCORE-363) Rename persistence property "datanucleus.messageCodesIncluded" to include "localisation" since in that category

[Andy J. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCCORE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Jefferson resolved NUCCORE-363.
------------------------------------

    Resolution: Fixed

SVN trunk has this

> Rename persistence property "datanucleus.messageCodesIncluded" to include "localisation" since in that category
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: NUCCORE-363
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-363
>             Project: DataNucleus Core
>          Issue Type: Task
>          Components: Code Structure
>            Reporter: Andy Jefferson
>            Assignee: Andy Jefferson
>             Fix For: 2.0.0.m2
>
>
> Rename to be "datanucleus.localisation.messageCodes"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Created: (NUCCORE-363) Rename persistence property "datanucleus.messageCodesIncluded" to include "localisation" since in that category

[Andy J. (JIRA) <web...@jp...>]

Rename persistence property "datanucleus.messageCodesIncluded" to include "localisation" since in that category
---------------------------------------------------------------------------------------------------------------

                 Key: NUCCORE-363
                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-363
             Project: DataNucleus Core
          Issue Type: Task
          Components: Code Structure
            Reporter: Andy Jefferson
            Assignee: Andy Jefferson
             Fix For: 2.0.0.m2


Rename to be "datanucleus.localisation.messageCodes"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Updated: (NUCRDBMS-247) Incorrect warning "Really you need a discriminator" when a base class reference to an extended abstract class is null

[Andy J. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Jefferson updated NUCRDBMS-247:
------------------------------------

    Priority: Minor  (was: Major)

Issue is not the query but instead the loading of related fields, and in that query there is a discriminator but it has no value since there is no result. Consequently nothing is affected and it is a logged warning only meaning the user is not impacted in the slightest, and the majority of users don't know what a log is :-) Downgraded to minor

> Incorrect warning "Really you need a discriminator" when a base class reference to an extended abstract class is null
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: NUCRDBMS-247
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-247
>             Project: DataNucleus RDBMS
>          Issue Type: Bug
>          Components: ORM
>    Affects Versions: 1.1.5
>         Environment: Win XP, MySQL, Intel Core 2 Duo, 4GB RAM
>            Reporter: Chris Colman
>            Priority: Minor
>         Attachments: incorrectNeedADiscriminatorWarning.zip, reallyYouNeedADiscriminatorWarning.jpg
>
>
> WIth the following class diagram:
>               ConcreteBase         -------------
>                            ^                                       |
>                            |                                        |
>                   AbstractExt1     <---------------
>                      ^              ^
>                      /                \
> ConcreteExt1Ext1   ConcreteExt1Ext2
> When loading the reference from ConcreteBase to AbstractExt1 AND that reference is null then an incorrect warning is produced:
>      [java] 2009/08/17 19:25:20.111 WARN  [DataNucleus.Persistence       ] Found type=class org.datanucleus.test.ConcreteExt1Ext2 but abstract and more than 1 concrete subclass. Really you need a discriminator  to help identifying the type. Choosing class org.datanucleus.test.ConcreteExt1Ext2
> Various aspects of this warning are incorrect as evidenced by the metadata contained in the provided test case.
> According to my reasoning there is nothing wrong with the class diagram nor its associated metadata and so the warning should not be produced for this scenario.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Commented: (NUCRDBMS-247) Incorrect warning "Really you need a discriminator" when a base class reference to an extended abstract class is null

[Chris C. (JIRA) <web...@jp...>]

    [ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945#action_16945 ] 

Chris Colman commented on NUCRDBMS-247:
---------------------------------------

I set the priority of this to Major in case there is something about this issue that affects the operation rather than just presenting a false warning. If the false warning is the only consequence of this issue then the priority should be reduced to minor.

> Incorrect warning "Really you need a discriminator" when a base class reference to an extended abstract class is null
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: NUCRDBMS-247
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-247
>             Project: DataNucleus RDBMS
>          Issue Type: Bug
>          Components: ORM
>    Affects Versions: 1.1.5
>         Environment: Win XP, MySQL, Intel Core 2 Duo, 4GB RAM
>            Reporter: Chris Colman
>         Attachments: incorrectNeedADiscriminatorWarning.zip, reallyYouNeedADiscriminatorWarning.jpg
>
>
> WIth the following class diagram:
>               ConcreteBase         -------------
>                            ^                                       |
>                            |                                        |
>                   AbstractExt1     <---------------
>                      ^              ^
>                      /                \
> ConcreteExt1Ext1   ConcreteExt1Ext2
> When loading the reference from ConcreteBase to AbstractExt1 AND that reference is null then an incorrect warning is produced:
>      [java] 2009/08/17 19:25:20.111 WARN  [DataNucleus.Persistence       ] Found type=class org.datanucleus.test.ConcreteExt1Ext2 but abstract and more than 1 concrete subclass. Really you need a discriminator  to help identifying the type. Choosing class org.datanucleus.test.ConcreteExt1Ext2
> Various aspects of this warning are incorrect as evidenced by the metadata contained in the provided test case.
> According to my reasoning there is nothing wrong with the class diagram nor its associated metadata and so the warning should not be produced for this scenario.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Updated: (NUCRDBMS-247) Incorrect warning "Really you need a discriminator" when a base class reference to an extended abstract class is null

[Chris C. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Colman updated NUCRDBMS-247:
----------------------------------

    Attachment: incorrectNeedADiscriminatorWarning.zip

Test case

> Incorrect warning "Really you need a discriminator" when a base class reference to an extended abstract class is null
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: NUCRDBMS-247
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-247
>             Project: DataNucleus RDBMS
>          Issue Type: Bug
>          Components: ORM
>    Affects Versions: 1.1.5
>         Environment: Win XP, MySQL, Intel Core 2 Duo, 4GB RAM
>            Reporter: Chris Colman
>         Attachments: incorrectNeedADiscriminatorWarning.zip, reallyYouNeedADiscriminatorWarning.jpg
>
>
> WIth the following class diagram:
>               ConcreteBase         -------------
>                            ^                                       |
>                            |                                        |
>                   AbstractExt1     <---------------
>                      ^              ^
>                      /                \
> ConcreteExt1Ext1   ConcreteExt1Ext2
> When loading the reference from ConcreteBase to AbstractExt1 AND that reference is null then an incorrect warning is produced:
>      [java] 2009/08/17 19:25:20.111 WARN  [DataNucleus.Persistence       ] Found type=class org.datanucleus.test.ConcreteExt1Ext2 but abstract and more than 1 concrete subclass. Really you need a discriminator  to help identifying the type. Choosing class org.datanucleus.test.ConcreteExt1Ext2
> Various aspects of this warning are incorrect as evidenced by the metadata contained in the provided test case.
> According to my reasoning there is nothing wrong with the class diagram nor its associated metadata and so the warning should not be produced for this scenario.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Updated: (NUCRDBMS-247) Incorrect warning "Really you need a discriminator" when a base class reference to an extended abstract class is null

[Chris C. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Colman updated NUCRDBMS-247:
----------------------------------

    Attachment: reallyYouNeedADiscriminatorWarning.jpg

Given the crippled ASCII class diagram I've attached an image to describe the class diagram that causes this warning.

> Incorrect warning "Really you need a discriminator" when a base class reference to an extended abstract class is null
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: NUCRDBMS-247
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-247
>             Project: DataNucleus RDBMS
>          Issue Type: Bug
>          Components: ORM
>    Affects Versions: 1.1.5
>         Environment: Win XP, MySQL, Intel Core 2 Duo, 4GB RAM
>            Reporter: Chris Colman
>         Attachments: reallyYouNeedADiscriminatorWarning.jpg
>
>
> WIth the following class diagram:
>               ConcreteBase         -------------
>                            ^                                       |
>                            |                                        |
>                   AbstractExt1     <---------------
>                      ^              ^
>                      /                \
> ConcreteExt1Ext1   ConcreteExt1Ext2
> When loading the reference from ConcreteBase to AbstractExt1 AND that reference is null then an incorrect warning is produced:
>      [java] 2009/08/17 19:25:20.111 WARN  [DataNucleus.Persistence       ] Found type=class org.datanucleus.test.ConcreteExt1Ext2 but abstract and more than 1 concrete subclass. Really you need a discriminator  to help identifying the type. Choosing class org.datanucleus.test.ConcreteExt1Ext2
> Various aspects of this warning are incorrect as evidenced by the metadata contained in the provided test case.
> According to my reasoning there is nothing wrong with the class diagram nor its associated metadata and so the warning should not be produced for this scenario.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Created: (NUCRDBMS-247) Incorrect warning "Really you need a discriminator" when a base class reference to an extended abstract class is null

[Chris C. (JIRA) <web...@jp...>]

Incorrect warning "Really you need a discriminator" when a base class reference to an extended abstract class is null
---------------------------------------------------------------------------------------------------------------------

                 Key: NUCRDBMS-247
                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-247
             Project: DataNucleus RDBMS
          Issue Type: Bug
          Components: ORM
    Affects Versions: 1.1.5
         Environment: Win XP, MySQL, Intel Core 2 Duo, 4GB RAM
            Reporter: Chris Colman


WIth the following class diagram:

              ConcreteBase         -------------
                           ^                                       |
                           |                                        |
                  AbstractExt1     <---------------
                     ^              ^
                     /                \
ConcreteExt1Ext1   ConcreteExt1Ext2

When loading the reference from ConcreteBase to AbstractExt1 AND that reference is null then an incorrect warning is produced:

     [java] 2009/08/17 19:25:20.111 WARN  [DataNucleus.Persistence       ] Found type=class org.datanucleus.test.ConcreteExt1Ext2 but abstract and more than 1 concrete subclass. Really you need a discriminator  to help identifying the type. Choosing class org.datanucleus.test.ConcreteExt1Ext2

Various aspects of this warning are incorrect as evidenced by the metadata contained in the provided test case.

According to my reasoning there is nothing wrong with the class diagram nor its associated metadata and so the warning should not be produced for this scenario.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Resolved: (NUCRDBMS-245) Select all columns in default fetch group at once when querying subclasses

[Andy J. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Jefferson resolved NUCRDBMS-245.
-------------------------------------

    Resolution: Won't Fix

"JDOQL2" (see the forum and DN blog) resolves such things hence won't be fixed in legacy JDOQL implementation

> Select all columns in default fetch group at once when querying subclasses
> --------------------------------------------------------------------------
>
>                 Key: NUCRDBMS-245
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-245
>             Project: DataNucleus RDBMS
>          Issue Type: Improvement
>          Components: Queries
>    Affects Versions: 1.1.5
>         Environment:         Java 1.6.0_13
>         MySQL Connector/J 5.1.7
>         DataNucleus 1.1.5
>            Reporter: Cyril Bouteille
>
> In the testcase attached @ http://www.datanucleus.org/servlet/forum/viewthread_thread,5695 Hotel extends WebContent.
> A simple newQuery(Hotel.class, "this.name == :name") generates a lot of SQL statement which could be optimized.
> 1) selecting THIS.ID first
> FINE: SELECT DISTINCT `THIS`.`ID` FROM `TEST_HOTEL` `THIS` WHERE `THIS`.`NAME` = <'Test'>
> 2) then select discriminator column for each ID in the result set
> FINE: SELECT `A1`.`WCMS_TYPE` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE 1 = `A0`.`ID`
> FINE: SELECT `A1`.`WCMS_TYPE` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE 6 = `A0`.`ID`
> 3) and if you add pm.makeTransientAll(hotelList, true) @ Main:49, it finally selects all the other fields on detach/transient step
> FINE: SELECT `A1`.`WCMS_PATH`,`A0`.`NAME` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE `A1`.`ID` = <1>
> FINE: SELECT `A1`.`WCMS_PATH`,`A0`.`NAME` FROM `TEST_HOTEL` `A0` INNER JOIN `TEST_WC` `A1` ON `A1`.`ID` = `A0`.`ID` WHERE `A1`.`ID` = <6>
> So if x is the # results returned by the query, it generates 1+2x queries.
> We have a lot of queries behaving in a similar way and scalability could be improved if some of all of the statements could be compacted.
> Could the first SELECT get all the columns from TEST_WC and TEST_HOTEL in default fetch group at once in (1)?
> Or at least combine (2) and (3)?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Resolved: (NUCRDBMS-246) Rename persistence property "datanucleus.rdbms.sql.allowAllSQLStatements" to be general and less verbose

[Andy J. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Jefferson resolved NUCRDBMS-246.
-------------------------------------

    Resolution: Fixed

SVN trunk renames this. Added to docs also

> Rename persistence property "datanucleus.rdbms.sql.allowAllSQLStatements" to be general and less verbose
> --------------------------------------------------------------------------------------------------------
>
>                 Key: NUCRDBMS-246
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-246
>             Project: DataNucleus RDBMS
>          Issue Type: Task
>          Components: Queries
>            Reporter: Andy Jefferson
>            Assignee: Andy Jefferson
>             Fix For: 2.0.0.m2
>
>
> Rename it to
> datanucleus.query.sql.allowAll
> so can apply to any datastore supporting SQL. Also move processing code down into "core"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Created: (NUCRDBMS-246) Rename persistence property "datanucleus.rdbms.sql.allowAllSQLStatements" to be general and less verbose

[Andy J. (JIRA) <web...@jp...>]

Rename persistence property "datanucleus.rdbms.sql.allowAllSQLStatements" to be general and less verbose
--------------------------------------------------------------------------------------------------------

                 Key: NUCRDBMS-246
                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-246
             Project: DataNucleus RDBMS
          Issue Type: Task
          Components: Queries
            Reporter: Andy Jefferson
            Assignee: Andy Jefferson
             Fix For: 2.0.0.m2


Rename it to
datanucleus.query.sql.allowAll
so can apply to any datastore supporting SQL. Also move processing code down into "core"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Resolved: (NUCCORE-362) Allow specification of embedded="true" on PC field to indicate embedded; currently require <embedded>/@Embedded

[Andy J. (JIRA) <web...@jp...>]

     [ http://www.datanucleus.org/servlet/jira/browse/NUCCORE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Jefferson resolved NUCCORE-362.
------------------------------------

    Resolution: Fixed

SVN trunk has this

> Allow specification of embedded="true" on PC field to indicate embedded; currently require <embedded>/@Embedded
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: NUCCORE-362
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-362
>             Project: DataNucleus Core
>          Issue Type: Task
>          Components: MetaData
>            Reporter: Andy Jefferson
>            Assignee: Andy Jefferson
>             Fix For: 2.0.0.m2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Created: (NUCCORE-362) Allow specification of embedded="true" on PC field to indicate embedded; currently require <embedded>/@Embedded

[Andy J. (JIRA) <web...@jp...>]

Allow specification of embedded="true" on PC field to indicate embedded; currently require <embedded>/@Embedded
---------------------------------------------------------------------------------------------------------------

                 Key: NUCCORE-362
                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-362
             Project: DataNucleus Core
          Issue Type: Task
          Components: MetaData
            Reporter: Andy Jefferson
            Assignee: Andy Jefferson
             Fix For: 2.0.0.m2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Commented: (NUCCORE-361) Unexpected flush for 1-to-1 + dependent="true" with optimistic lock

[Andy J. (JIRA) <web...@jp...>]

    [ http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939#action_16939 ] 

Andy Jefferson commented on NUCCORE-361:
----------------------------------------

Also, the DN unit tests seem to be run in some strange way. You have "NativeQueryTest", yet this is in a scenario for db4o (also CriteriaQueryTest). There is RelationshipTest in "test.jdo.orm.datastore" and "test.jdo.orm.application" yet this appears once and no idea which it is. You have "ApplicationIdentityTest" yet this works for me ... presumably under "test.jdo.application". Also "DatastoreIdPersistenceTest". Also ApplicationIdPersistenceTest.

> Unexpected flush for 1-to-1 + dependent="true" with optimistic lock 
> --------------------------------------------------------------------
>
>                 Key: NUCCORE-361
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361
>             Project: DataNucleus Core
>          Issue Type: Bug
>          Components: JDO
>    Affects Versions: 1.1.5, 2.0.0.m1
>            Reporter: Renato Garcia
>         Attachments: patch.txt, TCK-after.zip, TCK-before.zip, unit-test-result.zip
>
>
> A flush during causes problem to optimistic lock. See fourm details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Jpox-issues] [JPOX JIRA] Commented: (NUCCORE-361) Unexpected flush for 1-to-1 + dependent="true" with optimistic lock

[Andy J. (JIRA) <web...@jp...>]

    [ http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938#action_16938 ] 

Andy Jefferson commented on NUCCORE-361:
----------------------------------------

In the thread you say
<thread>Additionally to the flush problem there is a scenario that gives the exception below:
Exception in thread "A" Transient instances cant be deleted.
org.datanucleus.exceptions.NucleusUserException: Transient instances cant be deleted.
at org.datanucleus.ObjectManagerImpl.deleteObjectInternal(ObjectManagerImpl.java:1447)
at org.datanucleus.state.JDOStateManagerImpl.setObjectField(JDOStateManagerImpl.java:2440) </thread>

Please provide a testcase using the current samples that demonstrates this


The JDO TCK should pass fully. It does for me. It does for all other people on Apache JDO.

> Unexpected flush for 1-to-1 + dependent="true" with optimistic lock 
> --------------------------------------------------------------------
>
>                 Key: NUCCORE-361
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCCORE-361
>             Project: DataNucleus Core
>          Issue Type: Bug
>          Components: JDO
>    Affects Versions: 1.1.5, 2.0.0.m1
>            Reporter: Renato Garcia
>         Attachments: patch.txt, TCK-after.zip, TCK-before.zip, unit-test-result.zip
>
>
> A flush during causes problem to optimistic lock. See fourm details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira