[
https://issues.apache.org/jira/browse/CAY-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Thonfeld-Guckes updated CAY-2896:
---------------------------------------------
Description:
After upgrading from 4.1.1 to 4.2 we've noticed a regression. We have two
identical tables in two separate databases. Our integration test tries storing
one object in each table like so:
{code:java}
createObject in DbContext1
createObject in DbContext2
flush{code}
In all versions before 4.2 this worked fine. Internally the entities have
different names (CommonLog and PluginLog), but they're the same Java class and
the table names are the same in both databases.
>From version 4.2 on Cayenne started batching those requests which resulted in
>both entities being written to the PluginLog table. We've tried different
>orders of execution, the last table always wins. If we flush in between the
>create tasks, it works as before.
We found an issue in the *DbRowOp classes, that lead to this behaviour. The
isSameBatch functions don't check for different datamaps, when batching up
insert, update and delete statements.
I've created a PR for it which I will link after creating this ticket. I do
need some feedback, whether that's actually enough to fix the issue.
https://github.com/apache/cayenne/pull/630
was:
After upgrading from 4.1.1 to 4.2 we've noticed a regression. We have two
identical tables in two separate databases. Our integration test tries storing
one object in each table like so:
{code:java}
createObject in DbContext1
createObject in DbContext2
flush{code}
In all versions before 4.2 this worked fine. Internally the entities have
different names (CommonLog and PluginLog), but they're the same Java class and
the table names are the same in both databases.
>From version 4.2 on Cayenne started batching those requests which resulted in
>both entities being written to the PluginLog table. We've tried different
>orders of execution, the last table always wins. If we flush in between the
>create tasks, it works as before.
We found an issue in the *DbRowOp classes, that lead to this behaviour. The
isSameBatch functions don't check for different datamaps, when batching up
insert, update and delete statements.
I've created a PR for it which I will link after creating this ticket. I do
need some feedback, whether that's actually enough to fix the issue.
> Inserting two identical objects into two datamaps stores both objects in the
> last used datamap
> ----------------------------------------------------------------------------------------------
>
> Key: CAY-2896
> URL: https://issues.apache.org/jira/browse/CAY-2896
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
> Affects Versions: 4.2, 4.2.1, 4.2.2, 5.0-M1
> Reporter: Christopher Thonfeld-Guckes
> Priority: Major
> Labels: newbie, patch, pull-request-available
> Fix For: Undefined future
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After upgrading from 4.1.1 to 4.2 we've noticed a regression. We have two
> identical tables in two separate databases. Our integration test tries
> storing one object in each table like so:
> {code:java}
> createObject in DbContext1
> createObject in DbContext2
> flush{code}
> In all versions before 4.2 this worked fine. Internally the entities have
> different names (CommonLog and PluginLog), but they're the same Java class
> and the table names are the same in both databases.
> From version 4.2 on Cayenne started batching those requests which resulted in
> both entities being written to the PluginLog table. We've tried different
> orders of execution, the last table always wins. If we flush in between the
> create tasks, it works as before.
> We found an issue in the *DbRowOp classes, that lead to this behaviour. The
> isSameBatch functions don't check for different datamaps, when batching up
> insert, update and delete statements.
> I've created a PR for it which I will link after creating this ticket. I do
> need some feedback, whether that's actually enough to fix the issue.
> https://github.com/apache/cayenne/pull/630
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
