[jira] [Commented] (CAY-2852) Update velocity-engine-core dependency
[
https://issues.apache.org/jira/browse/CAY-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841247#comment-17841247
]
Nikita Timofeev commented on CAY-2852:
--
*4.2*:
https://github.com/apache/cayenne/commit/4bafafaddc0e71bf8686bc1a2a227e556c3a18b4
> Update velocity-engine-core dependency
> --
>
> Key: CAY-2852
> URL: https://issues.apache.org/jira/browse/CAY-2852
> Project: Cayenne
> Issue Type: Improvement
> Components: Modeler, Non-GUI Tools
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Minor
> Fix For: 4.2.1, 5.0-M1
>
>
> {code}
>
> org.apache.velocity
> velocity-engine-core
> 2.3
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2852) Update velocity-engine-core dependency
Nikita Timofeev created CAY-2852:
Summary: Update velocity-engine-core dependency
Key: CAY-2852
URL: https://issues.apache.org/jira/browse/CAY-2852
Project: Cayenne
Issue Type: Improvement
Components: Modeler, Non-GUI Tools
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 4.2.1, 5.0-M1
{code}
org.apache.velocity
velocity-engine-core
2.3
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAY-2851) Replace Existing OneToOne From New Object
[
https://issues.apache.org/jira/browse/CAY-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841189#comment-17841189
]
Nikita Timofeev commented on CAY-2851:
--
[~mattraydub] I like this fix, thank you! It's small enough to safely apply to
4.2 (and maybe even to 4.1).
There's a minor test failure, but it looks benign:
{code}
java.lang.AssertionError: expected:<4> but was:<5>
at
org.apache.cayenne.commitlog.CommitLogFilterIT.testPostCommit_UpdateToOne(CommitLogFilterIT.java:247)
{code}
> Replace Existing OneToOne From New Object
> -
>
> Key: CAY-2851
> URL: https://issues.apache.org/jira/browse/CAY-2851
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.2, 5.0-M1
>Reporter: Matt Watson
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a One to One (belongsTo on both sides) relationships between 2 Models
> (A & B), very similar to the Painting < - > PaintingInfo in the test
> environment.
> When we have an existing {{a1}} related to {{b1}} (and vice-versa b1 to a1),
> and we create a new b2. Then set {{{}b2.toA = a1{}}}. We find out that
> {{b1.toA}} is still related to {{a1}} instead of {{null}}
> The closest test that I found is in
> {code:java}
> CDOOneDep2OneIT.testReplace{code}
> but just need to set from the other side of the relationship instead.
> I can push up a breaking test soon. Not sure if you prefer it to be on
> {{master}} or {{{}STABLE-4.2{}}}.
> It seems that during {{b2.setToA(a1)}} the call to {{setToOneTarget("toA",
> a1, true)}} triggers a call to {{setReverseRelationship("toA", a1)}} , which
> triggers a call to {{{}setToOneTarget("toB", b2, false){}}}. In here it
> accesses the {{oldTarget}} which is {{{}b1{}}}. This is where I feel it
> should nullify {{b1.toA}} using {{{}unsetReverseRelationship("toB", b1){}}}.
> However, it does NOT because {{setReverse}} was passed in as {{{}false{}}}.
> Since it does not, at this point if you check the relationships:
> {{b2.toA == a1}} _GOOD_
> {{a1.toB == b2}} _GOOD_
> {{b1.toA == a1}} _BAD_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2851) Replace Existing OneToOne From New Object
[
https://issues.apache.org/jira/browse/CAY-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2851:
-
Affects Version/s: 4.1.1
4.0.3
> Replace Existing OneToOne From New Object
> -
>
> Key: CAY-2851
> URL: https://issues.apache.org/jira/browse/CAY-2851
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.0.3, 4.1.1, 4.2, 5.0-M1
>Reporter: Matt Watson
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a One to One (belongsTo on both sides) relationships between 2 Models
> (A & B), very similar to the Painting < - > PaintingInfo in the test
> environment.
> When we have an existing {{a1}} related to {{b1}} (and vice-versa b1 to a1),
> and we create a new b2. Then set {{{}b2.toA = a1{}}}. We find out that
> {{b1.toA}} is still related to {{a1}} instead of {{null}}
> The closest test that I found is in
> {code:java}
> CDOOneDep2OneIT.testReplace{code}
> but just need to set from the other side of the relationship instead.
> I can push up a breaking test soon. Not sure if you prefer it to be on
> {{master}} or {{{}STABLE-4.2{}}}.
> It seems that during {{b2.setToA(a1)}} the call to {{setToOneTarget("toA",
> a1, true)}} triggers a call to {{setReverseRelationship("toA", a1)}} , which
> triggers a call to {{{}setToOneTarget("toB", b2, false){}}}. In here it
> accesses the {{oldTarget}} which is {{{}b1{}}}. This is where I feel it
> should nullify {{b1.toA}} using {{{}unsetReverseRelationship("toB", b1){}}}.
> However, it does NOT because {{setReverse}} was passed in as {{{}false{}}}.
> Since it does not, at this point if you check the relationships:
> {{b2.toA == a1}} _GOOD_
> {{a1.toB == b2}} _GOOD_
> {{b1.toA == a1}} _BAD_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAY-2851) Replace Existing OneToOne From New Object
[
https://issues.apache.org/jira/browse/CAY-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev reassigned CAY-2851:
Assignee: Nikita Timofeev
> Replace Existing OneToOne From New Object
> -
>
> Key: CAY-2851
> URL: https://issues.apache.org/jira/browse/CAY-2851
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.2, 5.0-M1
>Reporter: Matt Watson
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a One to One (belongsTo on both sides) relationships between 2 Models
> (A & B), very similar to the Painting < - > PaintingInfo in the test
> environment.
> When we have an existing {{a1}} related to {{b1}} (and vice-versa b1 to a1),
> and we create a new b2. Then set {{{}b2.toA = a1{}}}. We find out that
> {{b1.toA}} is still related to {{a1}} instead of {{null}}
> The closest test that I found is in
> {code:java}
> CDOOneDep2OneIT.testReplace{code}
> but just need to set from the other side of the relationship instead.
> I can push up a breaking test soon. Not sure if you prefer it to be on
> {{master}} or {{{}STABLE-4.2{}}}.
> It seems that during {{b2.setToA(a1)}} the call to {{setToOneTarget("toA",
> a1, true)}} triggers a call to {{setReverseRelationship("toA", a1)}} , which
> triggers a call to {{{}setToOneTarget("toB", b2, false){}}}. In here it
> accesses the {{oldTarget}} which is {{{}b1{}}}. This is where I feel it
> should nullify {{b1.toA}} using {{{}unsetReverseRelationship("toB", b1){}}}.
> However, it does NOT because {{setReverse}} was passed in as {{{}false{}}}.
> Since it does not, at this point if you check the relationships:
> {{b2.toA == a1}} _GOOD_
> {{a1.toB == b2}} _GOOD_
> {{b1.toA == a1}} _BAD_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2851) Replace Existing OneToOne From New Object
[
https://issues.apache.org/jira/browse/CAY-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2851:
-
Fix Version/s: 4.2.1
5.0-M1
> Replace Existing OneToOne From New Object
> -
>
> Key: CAY-2851
> URL: https://issues.apache.org/jira/browse/CAY-2851
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.2, 5.0-M2
>Reporter: Matt Watson
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a One to One (belongsTo on both sides) relationships between 2 Models
> (A & B), very similar to the Painting < - > PaintingInfo in the test
> environment.
> When we have an existing {{a1}} related to {{b1}} (and vice-versa b1 to a1),
> and we create a new b2. Then set {{{}b2.toA = a1{}}}. We find out that
> {{b1.toA}} is still related to {{a1}} instead of {{null}}
> The closest test that I found is in
> {code:java}
> CDOOneDep2OneIT.testReplace{code}
> but just need to set from the other side of the relationship instead.
> I can push up a breaking test soon. Not sure if you prefer it to be on
> {{master}} or {{{}STABLE-4.2{}}}.
> It seems that during {{b2.setToA(a1)}} the call to {{setToOneTarget("toA",
> a1, true)}} triggers a call to {{setReverseRelationship("toA", a1)}} , which
> triggers a call to {{{}setToOneTarget("toB", b2, false){}}}. In here it
> accesses the {{oldTarget}} which is {{{}b1{}}}. This is where I feel it
> should nullify {{b1.toA}} using {{{}unsetReverseRelationship("toB", b1){}}}.
> However, it does NOT because {{setReverse}} was passed in as {{{}false{}}}.
> Since it does not, at this point if you check the relationships:
> {{b2.toA == a1}} _GOOD_
> {{a1.toB == b2}} _GOOD_
> {{b1.toA == a1}} _BAD_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2851) Replace Existing OneToOne From New Object
[
https://issues.apache.org/jira/browse/CAY-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2851:
-
Affects Version/s: 5.0-M1
(was: 5.0-M2)
> Replace Existing OneToOne From New Object
> -
>
> Key: CAY-2851
> URL: https://issues.apache.org/jira/browse/CAY-2851
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.2, 5.0-M1
>Reporter: Matt Watson
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a One to One (belongsTo on both sides) relationships between 2 Models
> (A & B), very similar to the Painting < - > PaintingInfo in the test
> environment.
> When we have an existing {{a1}} related to {{b1}} (and vice-versa b1 to a1),
> and we create a new b2. Then set {{{}b2.toA = a1{}}}. We find out that
> {{b1.toA}} is still related to {{a1}} instead of {{null}}
> The closest test that I found is in
> {code:java}
> CDOOneDep2OneIT.testReplace{code}
> but just need to set from the other side of the relationship instead.
> I can push up a breaking test soon. Not sure if you prefer it to be on
> {{master}} or {{{}STABLE-4.2{}}}.
> It seems that during {{b2.setToA(a1)}} the call to {{setToOneTarget("toA",
> a1, true)}} triggers a call to {{setReverseRelationship("toA", a1)}} , which
> triggers a call to {{{}setToOneTarget("toB", b2, false){}}}. In here it
> accesses the {{oldTarget}} which is {{{}b1{}}}. This is where I feel it
> should nullify {{b1.toA}} using {{{}unsetReverseRelationship("toB", b1){}}}.
> However, it does NOT because {{setReverse}} was passed in as {{{}false{}}}.
> Since it does not, at this point if you check the relationships:
> {{b2.toA == a1}} _GOOD_
> {{a1.toB == b2}} _GOOD_
> {{b1.toA == a1}} _BAD_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2849) Switch documentation to `hugo-asciidoctorj-extension`
Nikita Timofeev created CAY-2849:
Summary: Switch documentation to `hugo-asciidoctorj-extension`
Key: CAY-2849
URL: https://issues.apache.org/jira/browse/CAY-2849
Project: Cayenne
Issue Type: Improvement
Components: Documentation
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 4.0.4, 4.1.2, 4.2.1, 5.0-M1
We could switch documentation from internal AsciidoctorJ extenstion to
{{io.bootique.tools:hugo-asciidoctorj-extension}} that supports multipage
rendering.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2835) Custom aggregate functions
[ https://issues.apache.org/jira/browse/CAY-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev closed CAY-2835. Resolution: Fixed https://github.com/apache/cayenne/pull/609 > Custom aggregate functions > -- > > Key: CAY-2835 > URL: https://issues.apache.org/jira/browse/CAY-2835 > Project: Cayenne > Issue Type: Improvement > Components: Core Library >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Minor > Fix For: 5.0-M1 > > Time Spent: 40m > Remaining Estimate: 0h > > We already have support for custom SQL operators and functions, but there's > no easy way to use custom aggregate functions. > See also this thread: > https://lists.apache.org/thread/hqwm68200m7od24zzvypmxq84fdp6y9q -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAY-2848) Vertical Inheritance: Updating one-to-many with inverse nullifies other columns.
[ https://issues.apache.org/jira/browse/CAY-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev reassigned CAY-2848: Assignee: Nikita Timofeev > Vertical Inheritance: Updating one-to-many with inverse nullifies other > columns. > > > Key: CAY-2848 > URL: https://issues.apache.org/jira/browse/CAY-2848 > Project: Cayenne > Issue Type: Bug >Affects Versions: 4.2 >Reporter: Jadon Hansell >Assignee: Nikita Timofeev >Priority: Major > Fix For: 4.2.1, 5.0-M1 > > Attachments: update-flattened-relationship-nullify-other-columns.patch > > > When there is a one-to-many relationship on the child DbEntity of a vertical > inheritance scenario, giving it an inverse fails when the relationship is > updated to anything non-null. > An update query is issued that contains the PK of the child row and the new > ID for the relationship, but sets every other column to null. I've included a > breaking test as a patch in 4.2-STABLE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2848) Vertical Inheritance: Updating one-to-many with inverse nullifies other columns.
[ https://issues.apache.org/jira/browse/CAY-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev updated CAY-2848: - Affects Version/s: 4.2 > Vertical Inheritance: Updating one-to-many with inverse nullifies other > columns. > > > Key: CAY-2848 > URL: https://issues.apache.org/jira/browse/CAY-2848 > Project: Cayenne > Issue Type: Bug >Affects Versions: 4.2 >Reporter: Jadon Hansell >Priority: Major > Attachments: update-flattened-relationship-nullify-other-columns.patch > > > When there is a one-to-many relationship on the child DbEntity of a vertical > inheritance scenario, giving it an inverse fails when the relationship is > updated to anything non-null. > An update query is issued that contains the PK of the child row and the new > ID for the relationship, but sets every other column to null. I've included a > breaking test as a patch in 4.2-STABLE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2848) Vertical Inheritance: Updating one-to-many with inverse nullifies other columns.
[ https://issues.apache.org/jira/browse/CAY-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev updated CAY-2848: - Fix Version/s: 4.2.1 5.0-M1 > Vertical Inheritance: Updating one-to-many with inverse nullifies other > columns. > > > Key: CAY-2848 > URL: https://issues.apache.org/jira/browse/CAY-2848 > Project: Cayenne > Issue Type: Bug >Affects Versions: 4.2 >Reporter: Jadon Hansell >Priority: Major > Fix For: 4.2.1, 5.0-M1 > > Attachments: update-flattened-relationship-nullify-other-columns.patch > > > When there is a one-to-many relationship on the child DbEntity of a vertical > inheritance scenario, giving it an inverse fails when the relationship is > updated to anything non-null. > An update query is issued that contains the PK of the child row and the new > ID for the relationship, but sets every other column to null. I've included a > breaking test as a patch in 4.2-STABLE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2814) Select query iterator() and batchIterator() methods return incorrect results
[
https://issues.apache.org/jira/browse/CAY-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2814:
-
Affects Version/s: 4.1
4.1.2
4.2.1
> Select query iterator() and batchIterator() methods return incorrect results
>
>
> Key: CAY-2814
> URL: https://issues.apache.org/jira/browse/CAY-2814
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.1, 4.1.1, 4.2.RC1, 4.1.2, 4.2, 4.2.1
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Iterated queries can handle only basic results like single entity,
> {{Object[]}} and {{DataRow}}
> everything else is missing in the processing.
> This affects ColumnQuery most as it can return many more variants.
> What variants are broken:
> * all selects: joint prefetches
> * column query: several entities or entity + some other fields
> * column query: embeddables
> * column query: map function (see CAY-2812)
> * maybe something else (?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2844) Joint prefetch doesn't use ObjEntity qualifier
[ https://issues.apache.org/jira/browse/CAY-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev closed CAY-2844. Resolution: Fixed *5.0*: https://github.com/apache/cayenne/commit/55acf42bcd29f3d663f5e343d20e8f681c856c43 *4.2*: https://github.com/apache/cayenne/commit/1124cb9deca380f68449a1cdc50f86e71eb96f54 > Joint prefetch doesn't use ObjEntity qualifier > -- > > Key: CAY-2844 > URL: https://issues.apache.org/jira/browse/CAY-2844 > Project: Cayenne > Issue Type: Bug > Components: Core Library >Affects Versions: 4.2 >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 4.2.1, 5.0-M1 > > > Joint prefetch ignores existing qualifier on ObjEntity. > Disjoint and DisjointById prefetches are working fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAY-2838) Vertical Inheritance: Problem setting db attribute to null via flattened path
[
https://issues.apache.org/jira/browse/CAY-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2838.
Resolution: Fixed
New fix is ready
*5.0*:
https://github.com/apache/cayenne/commit/e60ac710be75799a735bbe1a458b4ba09704a5c7
*4.2*:
https://github.com/apache/cayenne/commit/cc51de1baecc1e67e08206a9603d8618cb91aecd
+ following commits
> Vertical Inheritance: Problem setting db attribute to null via flattened path
> -
>
> Key: CAY-2838
> URL: https://issues.apache.org/jira/browse/CAY-2838
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.2
> Environment: Cayenne 4.2, Java 17, MacOS 14
>Reporter: Jadon Hansell
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Attachments: NullifyFlattenedTests.patch,
> concrete-to-abstract-error.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While using vertical inheritance, I ran into a bug with a non-required
> attribute on a child {{{}DbEntity{}}}. The issue occurs when an attribute,
> accessed via a flattened path like '{{{}child.attr{}}}' on the child's
> {{{}ObjEntity{}}}, is initially set to a value and then later changed to
> null. This causes Cayenne to attempt to set the primary key of the {{child}}
> db entity to null as well.
> I've attached a patch that contains failing tests demonstrating this issue on
> both an ObjEntity's attribute and a belongs-to relationship.
> A temporary workaround I've used is to relocate these columns to the parent
> DbEntity so the path isn't flattened.
>
> The root of the problem appears to start in the
> {{{}ValuesCreationHandler{}}}. During the operation, it runs
> {{processFlattenedPath}} to identify the target row's ID, with
> {{{}add=false{}}}. This then iterates through the db path components and
> invokes {{processRelationship}} for each db relationship, again with
> {{{}add=false{}}}.
> While processing the first path component, {{processRelationship}} creates an
> {{UPDATE}} row operation, attempting to update the child's uuid to its
> current value (case 2 in the comments). Normally, this would not cause an
> error. But, because the '{{{}add'{}}} parameter is set to false, the
> {{ValuePropagationVisitor}} replaces the current ID with null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2814) Select query iterator() and batchIterator() methods return incorrect results
[
https://issues.apache.org/jira/browse/CAY-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2814:
-
Fix Version/s: (was: 4.2.1)
> Select query iterator() and batchIterator() methods return incorrect results
>
>
> Key: CAY-2814
> URL: https://issues.apache.org/jira/browse/CAY-2814
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.1.1, 4.2.RC1, 4.2
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Iterated queries can handle only basic results like single entity,
> {{Object[]}} and {{DataRow}}
> everything else is missing in the processing.
> This affects ColumnQuery most as it can return many more variants.
> What variants are broken:
> * all selects: joint prefetches
> * column query: several entities or entity + some other fields
> * column query: embeddables
> * column query: map function (see CAY-2812)
> * maybe something else (?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2841) Multi column ColumnSelect with SHARED_CACHE fails after 1st select
[
https://issues.apache.org/jira/browse/CAY-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2841.
Resolution: Fixed
*4.2*:
https://github.com/apache/cayenne/commit/c987980c7229782cd813966d6dfc56a67bccea15
> Multi column ColumnSelect with SHARED_CACHE fails after 1st select
> --
>
> Key: CAY-2841
> URL: https://issues.apache.org/jira/browse/CAY-2841
> Project: Cayenne
> Issue Type: Bug
>Affects Versions: 4.2
>Reporter: Jurgen Doll
>Assignee: Nikita Timofeev
>Priority: Minor
> Fix For: 4.2.1, 5.0-M1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Adding the following test case to
> {color:#00}{color:#00}ColumnSelectIT{color}{color} shows the problem:
>
> {color:#00} {color}{color:#646464}@{color}{color:#00}Test{color}
> {color:#00} {color}{color:#7f0055}public{color}{color:#00}
> {color}{color:#7f0055}void{color}{color:#00} testSharedCache()
> {color}{color:#7f0055}throws{color}{color:#00} Exception {{color}
> {color:#00} ColumnSelect colQry = ObjectSelect.query(
> Artist.{color}{color:#7f0055}class{color}{color:#00} ){color}
> {color:#00} .columns( Artist.ARTIST_NAME, Artist.DATE_OF_BIRTH ){color}
> {color:#00} .cacheStrategy( QueryCacheStrategy.SHARED_CACHE );{color}
> {color:#00} {color}
> {color:#00} List result = colQry.select(context);{color}
> {color:#00} assertEquals(20, result.size());{color}
>
> {color:#00} {color}{color:#3f7f5f}// Next line fails with
> UnsupportedOperationException{color}
> {color:#00} List result2 = colQry.select(context);{color}
> {color:#00} assertEquals(20, result.size());{color}
> {color:#00} }{color}
>
> Stacktrace:
>
> {color:#ff}Exception in thread "JavaFX Application Thread"
> {color}{color:#0066cc}java.lang.UnsupportedOperationException{color}
> {color:#ff} at
> java.base/java.util.Collections$UnmodifiableCollection.removeIf({color}{color:#0066cc}Collections.java:1120{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction$MixedConversionStrategy.convert({color}{color:#0066cc}DataDomainQueryAction.java:818{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction.interceptObjectConversion({color}{color:#0066cc}DataDomainQueryAction.java:507{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction.execute({color}{color:#0066cc}DataDomainQueryAction.java:135{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain.onQueryNoFilters({color}{color:#0066cc}DataDomain.java:570{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain$DataDomainQueryFilterChain.onQuery({color}{color:#0066cc}DataDomain.java:819{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain.onQuery({color}{color:#0066cc}DataDomain.java:562{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.runQuery({color}{color:#0066cc}ObjectContextQueryAction.java:406{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.executePostCache({color}{color:#0066cc}ObjectContextQueryAction.java:107{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.execute({color}{color:#0066cc}ObjectContextQueryAction.java:94{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataContext.onQuery({color}{color:#0066cc}DataContext.java:960{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataContext.performQuery({color}{color:#0066cc}DataContext.java:949{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.BaseContext.select({color}{color:#0066cc}BaseContext.java:307{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.query.FluentSelect.select({color}{color:#0066cc}FluentSelect.java:160{color}{color:#ff}){color}
>
> Workaround: Add
> {color:#00}{color:#00}.suppressDistinct(){color}{color} to the query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAY-2838) Vertical Inheritance: Problem setting db attribute to null via flattened path
[
https://issues.apache.org/jira/browse/CAY-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821816#comment-17821816
]
Nikita Timofeev commented on CAY-2838:
--
[~jhansell] I suspected that it could be the case and thank you for the test.
> Vertical Inheritance: Problem setting db attribute to null via flattened path
> -
>
> Key: CAY-2838
> URL: https://issues.apache.org/jira/browse/CAY-2838
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.2
> Environment: Cayenne 4.2, Java 17, MacOS 14
>Reporter: Jadon Hansell
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Attachments: NullifyFlattenedTests.patch,
> concrete-to-abstract-error.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While using vertical inheritance, I ran into a bug with a non-required
> attribute on a child {{{}DbEntity{}}}. The issue occurs when an attribute,
> accessed via a flattened path like '{{{}child.attr{}}}' on the child's
> {{{}ObjEntity{}}}, is initially set to a value and then later changed to
> null. This causes Cayenne to attempt to set the primary key of the {{child}}
> db entity to null as well.
> I've attached a patch that contains failing tests demonstrating this issue on
> both an ObjEntity's attribute and a belongs-to relationship.
> A temporary workaround I've used is to relocate these columns to the parent
> DbEntity so the path isn't flattened.
>
> The root of the problem appears to start in the
> {{{}ValuesCreationHandler{}}}. During the operation, it runs
> {{processFlattenedPath}} to identify the target row's ID, with
> {{{}add=false{}}}. This then iterates through the db path components and
> invokes {{processRelationship}} for each db relationship, again with
> {{{}add=false{}}}.
> While processing the first path component, {{processRelationship}} creates an
> {{UPDATE}} row operation, attempting to update the child's uuid to its
> current value (case 2 in the comments). Normally, this would not cause an
> error. But, because the '{{{}add'{}}} parameter is set to false, the
> {{ValuePropagationVisitor}} replaces the current ID with null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2838) Vertical Inheritance: Problem setting db attribute to null via flattened path
[
https://issues.apache.org/jira/browse/CAY-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2838.
Resolution: Fixed
*4.2*:
https://github.com/apache/cayenne/commit/2361f20a74bc6178f9dab40f0920e2a4f2aa6f00
> Vertical Inheritance: Problem setting db attribute to null via flattened path
> -
>
> Key: CAY-2838
> URL: https://issues.apache.org/jira/browse/CAY-2838
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.2
> Environment: Cayenne 4.2, Java 17, MacOS 14
>Reporter: Jadon Hansell
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Attachments: NullifyFlattenedTests.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While using vertical inheritance, I ran into a bug with a non-required
> attribute on a child {{{}DbEntity{}}}. The issue occurs when an attribute,
> accessed via a flattened path like '{{{}child.attr{}}}' on the child's
> {{{}ObjEntity{}}}, is initially set to a value and then later changed to
> null. This causes Cayenne to attempt to set the primary key of the {{child}}
> db entity to null as well.
> I've attached a patch that contains failing tests demonstrating this issue on
> both an ObjEntity's attribute and a belongs-to relationship.
> A temporary workaround I've used is to relocate these columns to the parent
> DbEntity so the path isn't flattened.
>
> The root of the problem appears to start in the
> {{{}ValuesCreationHandler{}}}. During the operation, it runs
> {{processFlattenedPath}} to identify the target row's ID, with
> {{{}add=false{}}}. This then iterates through the db path components and
> invokes {{processRelationship}} for each db relationship, again with
> {{{}add=false{}}}.
> While processing the first path component, {{processRelationship}} creates an
> {{UPDATE}} row operation, attempting to update the child's uuid to its
> current value (case 2 in the comments). Normally, this would not cause an
> error. But, because the '{{{}add'{}}} parameter is set to false, the
> {{ValuePropagationVisitor}} replaces the current ID with null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2846) Modeler: Allow to disable some validation rules in the project
Nikita Timofeev created CAY-2846: Summary: Modeler: Allow to disable some validation rules in the project Key: CAY-2846 URL: https://issues.apache.org/jira/browse/CAY-2846 Project: Cayenne Issue Type: Improvement Components: Modeler Reporter: Nikita Timofeev Fix For: 5.0-M2 We have pretty extensive set of validation rules in the Modeler, but they could go against existing project policy. So on some projects it's almost impossible to use validation because of a long list of unrelated problems. It would be nice if we could disable some checks on a per-project basis. Also we may need to improve visualization of found problems, preferably add some icons right in the main UI (though it could be challenging). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAY-2845) Deprecate DataObject in favour of Persistent
[
https://issues.apache.org/jira/browse/CAY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2845.
Resolution: Fixed
> Deprecate DataObject in favour of Persistent
>
>
> Key: CAY-2845
> URL: https://issues.apache.org/jira/browse/CAY-2845
> Project: Cayenne
> Issue Type: Task
> Components: cgen, Core Library
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
>
> Historically we got two parallel hierarchies for persistent objects for
> server and client parts. Since we removed ROP completely we can now reduce
> this to just one interface and base class.
> So this task proposes to deprecate {{DataObject}} interface and
> {{BaseDataObject}} class, and make {{Persistent}} interface with the
> {{PersistentObject}} base class the single implementation throughout Cayenne
> stack.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2845) Deprecate DataObject in favour of Persistent
Nikita Timofeev created CAY-2845:
Summary: Deprecate DataObject in favour of Persistent
Key: CAY-2845
URL: https://issues.apache.org/jira/browse/CAY-2845
Project: Cayenne
Issue Type: Task
Components: cgen, Core Library
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 5.0-M1
Historically we got two parallel hierarchies for persistent objects for server
and client parts. Since we removed ROP completely we can now reduce this to
just one interface and base class.
So this task proposes to deprecate {{DataObject}} interface and
{{BaseDataObject}} class, and make {{Persistent}} interface with the
{{PersistentObject}} base class the single implementation throughout Cayenne
stack.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2839) Postgresql connection fails to escape column name if it is a reserved word, line "end".
[
https://issues.apache.org/jira/browse/CAY-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2839.
Resolution: Won't Fix
> Postgresql connection fails to escape column name if it is a reserved word,
> line "end".
> ---
>
> Key: CAY-2839
> URL: https://issues.apache.org/jira/browse/CAY-2839
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library, Modeler
>Affects Versions: 4.2
> Environment: JDK21
>Reporter: Roland Szabó
>Priority: Major
>
> As seen in the sample stack trace, I have a database table in postgresql
> named "end". Because this is a reserved word, it should be quoted, but the
> postgresql connector does not quote column names in queries nor in Modeler,
> when I request SQL generation. The SQL generated by the Modeler can easily be
> fixed, but the queries fail.
> I have tried it with the latest postgresql library available in maven.
> {{2024-01-30 17:19:43 [apache-cayenne]
> org.apache.cayenne.log.Slf4jJdbcEventLogger logQueryError}}
> {{ INFO: *** error.}}
> {{ org.postgresql.util.PSQLException: ERROR: syntax error at or near "end"}}
> {{ Position: 26}}
> {{ at
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2676)}}
> {{ at
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2366)}}
> {{ at
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:356)}}
> {{ at
> org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:496)}}
> {{ at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:413)}}
> {{ at
> org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:190)}}
> {{ at
> org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:152)}}
> {{ at
> org.apache.cayenne.access.jdbc.BatchAction.runAsIndividualQueries(BatchAction.java:196)}}
> {{ at
> org.apache.cayenne.access.jdbc.BatchAction.performAction(BatchAction.java:93)}}
> {{ at
> org.apache.cayenne.access.DataNodeQueryAction.runQuery(DataNodeQueryAction.java:97)}}
> {{ at
> org.apache.cayenne.access.DataNode.performQueries(DataNode.java:273)}}
> {{ at
> org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.lambda$executeQueries$6(DefaultDataDomainFlushAction.java:178)}}
> {{ at java.base/java.util.HashMap.forEach(HashMap.java:1429)}}
> {{ at
> org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.executeQueries(DefaultDataDomainFlushAction.java:177)}}
> {{ at
> org.apache.cayenne.access.flush.DefaultDataDomainFlushAction.flush(DefaultDataDomainFlushAction.java:90)}}
> {{ at
> org.apache.cayenne.access.DataDomain.onSyncFlush(DataDomain.java:637)}}
> {{ at
> org.apache.cayenne.access.DataDomain.onSyncNoFilters(DataDomain.java:609)}}
> {{ at
> org.apache.cayenne.access.DataDomain$DataDomainSyncFilterChain.onSync(DataDomain.java:835)}}
> {{ at
> org.apache.cayenne.tx.TransactionFilter.lambda$onSync$0(TransactionFilter.java:61)}}
> {{ at
> org.apache.cayenne.tx.DefaultTransactionManager$BaseTransactionHandler.performInTransaction(DefaultTransactionManager.java:180)}}
> {{ at
> org.apache.cayenne.tx.DefaultTransactionManager$NestedTransactionHandler.handle(DefaultTransactionManager.java:93)}}
> {{ at
> org.apache.cayenne.tx.DefaultTransactionManager.performInTransaction(DefaultTransactionManager.java:62)}}
> {{ at
> org.apache.cayenne.tx.DefaultTransactionManager.performInTransaction(DefaultTransactionManager.java:40)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2844) Joint prefetch doesn't use ObjEntity qualifier
[ https://issues.apache.org/jira/browse/CAY-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev updated CAY-2844: - Summary: Joint prefetch doesn't use ObjEntity qualifier (was: Joint prefetch doesn't use entity qualifier) > Joint prefetch doesn't use ObjEntity qualifier > -- > > Key: CAY-2844 > URL: https://issues.apache.org/jira/browse/CAY-2844 > Project: Cayenne > Issue Type: Bug > Components: Core Library >Affects Versions: 4.2 >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 4.2.1, 5.0-M1 > > > Joint prefetch ignores existing qualifier on ObjEntity. > Disjoint and DisjointById prefetches are working fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2844) Joint prefetch doesn't use entity qualifier
Nikita Timofeev created CAY-2844: Summary: Joint prefetch doesn't use entity qualifier Key: CAY-2844 URL: https://issues.apache.org/jira/browse/CAY-2844 Project: Cayenne Issue Type: Bug Components: Core Library Affects Versions: 4.2 Reporter: Nikita Timofeev Assignee: Nikita Timofeev Fix For: 4.2.1, 5.0-M1 Joint prefetch ignores existing qualifier on ObjEntity. Disjoint and DisjointById prefetches are working fine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAY-2843) Use an IN clause for single field disjoint by ID prefetches
[ https://issues.apache.org/jira/browse/CAY-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev reassigned CAY-2843: Assignee: Nikita Timofeev > Use an IN clause for single field disjoint by ID prefetches > --- > > Key: CAY-2843 > URL: https://issues.apache.org/jira/browse/CAY-2843 > Project: Cayenne > Issue Type: Improvement > Components: Core Library >Affects Versions: 4.2 >Reporter: Jurgen Doll >Assignee: Nikita Timofeev >Priority: Minor > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently HierarchicalObjectResolver uses "field1 = ? OR field1 = ? " > pattern for all disjoint by ID prefetches. > I propose distinguishing between single field prefetches and multi-field > prefetches, so that the former makes use of an IN clause instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2843) Use an IN clause for single field disjoint by ID prefetches
[ https://issues.apache.org/jira/browse/CAY-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev updated CAY-2843: - Fix Version/s: 5.0-M1 > Use an IN clause for single field disjoint by ID prefetches > --- > > Key: CAY-2843 > URL: https://issues.apache.org/jira/browse/CAY-2843 > Project: Cayenne > Issue Type: Improvement > Components: Core Library >Affects Versions: 4.2 >Reporter: Jurgen Doll >Assignee: Nikita Timofeev >Priority: Minor > Labels: pull-request-available > Fix For: 5.0-M1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently HierarchicalObjectResolver uses "field1 = ? OR field1 = ? " > pattern for all disjoint by ID prefetches. > I propose distinguishing between single field prefetches and multi-field > prefetches, so that the former makes use of an IN clause instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAY-2841) Multi column ColumnSelect with SHARED_CACHE fails after 1st select
[
https://issues.apache.org/jira/browse/CAY-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815669#comment-17815669
]
Nikita Timofeev commented on CAY-2841:
--
Opened a draft PR: https://github.com/apache/cayenne/pull/607
> Multi column ColumnSelect with SHARED_CACHE fails after 1st select
> --
>
> Key: CAY-2841
> URL: https://issues.apache.org/jira/browse/CAY-2841
> Project: Cayenne
> Issue Type: Bug
>Affects Versions: 4.2
>Reporter: Jurgen Doll
>Assignee: Nikita Timofeev
>Priority: Minor
> Fix For: 4.2.1, 5.0-M1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Adding the following test case to
> {color:#00}{color:#00}ColumnSelectIT{color}{color} shows the problem:
>
> {color:#00} {color}{color:#646464}@{color}{color:#00}Test{color}
> {color:#00} {color}{color:#7f0055}public{color}{color:#00}
> {color}{color:#7f0055}void{color}{color:#00} testSharedCache()
> {color}{color:#7f0055}throws{color}{color:#00} Exception {{color}
> {color:#00} ColumnSelect colQry = ObjectSelect.query(
> Artist.{color}{color:#7f0055}class{color}{color:#00} ){color}
> {color:#00} .columns( Artist.ARTIST_NAME, Artist.DATE_OF_BIRTH ){color}
> {color:#00} .cacheStrategy( QueryCacheStrategy.SHARED_CACHE );{color}
> {color:#00} {color}
> {color:#00} List result = colQry.select(context);{color}
> {color:#00} assertEquals(20, result.size());{color}
>
> {color:#00} {color}{color:#3f7f5f}// Next line fails with
> UnsupportedOperationException{color}
> {color:#00} List result2 = colQry.select(context);{color}
> {color:#00} assertEquals(20, result.size());{color}
> {color:#00} }{color}
>
> Stacktrace:
>
> {color:#ff}Exception in thread "JavaFX Application Thread"
> {color}{color:#0066cc}java.lang.UnsupportedOperationException{color}
> {color:#ff} at
> java.base/java.util.Collections$UnmodifiableCollection.removeIf({color}{color:#0066cc}Collections.java:1120{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction$MixedConversionStrategy.convert({color}{color:#0066cc}DataDomainQueryAction.java:818{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction.interceptObjectConversion({color}{color:#0066cc}DataDomainQueryAction.java:507{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction.execute({color}{color:#0066cc}DataDomainQueryAction.java:135{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain.onQueryNoFilters({color}{color:#0066cc}DataDomain.java:570{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain$DataDomainQueryFilterChain.onQuery({color}{color:#0066cc}DataDomain.java:819{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain.onQuery({color}{color:#0066cc}DataDomain.java:562{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.runQuery({color}{color:#0066cc}ObjectContextQueryAction.java:406{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.executePostCache({color}{color:#0066cc}ObjectContextQueryAction.java:107{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.execute({color}{color:#0066cc}ObjectContextQueryAction.java:94{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataContext.onQuery({color}{color:#0066cc}DataContext.java:960{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataContext.performQuery({color}{color:#0066cc}DataContext.java:949{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.BaseContext.select({color}{color:#0066cc}BaseContext.java:307{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.query.FluentSelect.select({color}{color:#0066cc}FluentSelect.java:160{color}{color:#ff}){color}
>
> Workaround: Add
> {color:#00}{color:#00}.suppressDistinct(){color}{color} to the query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAY-2841) Multi column ColumnSelect with SHARED_CACHE fails after 1st select
[
https://issues.apache.org/jira/browse/CAY-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev reassigned CAY-2841:
Assignee: Nikita Timofeev
> Multi column ColumnSelect with SHARED_CACHE fails after 1st select
> --
>
> Key: CAY-2841
> URL: https://issues.apache.org/jira/browse/CAY-2841
> Project: Cayenne
> Issue Type: Bug
>Affects Versions: 4.2
>Reporter: Jurgen Doll
>Assignee: Nikita Timofeev
>Priority: Minor
> Fix For: 4.2.1, 5.0-M1
>
>
> Adding the following test case to
> {color:#00}{color:#00}ColumnSelectIT{color}{color} shows the problem:
>
> {color:#00} {color}{color:#646464}@{color}{color:#00}Test{color}
> {color:#00} {color}{color:#7f0055}public{color}{color:#00}
> {color}{color:#7f0055}void{color}{color:#00} testSharedCache()
> {color}{color:#7f0055}throws{color}{color:#00} Exception {{color}
> {color:#00} ColumnSelect colQry = ObjectSelect.query(
> Artist.{color}{color:#7f0055}class{color}{color:#00} ){color}
> {color:#00} .columns( Artist.ARTIST_NAME, Artist.DATE_OF_BIRTH ){color}
> {color:#00} .cacheStrategy( QueryCacheStrategy.SHARED_CACHE );{color}
> {color:#00} {color}
> {color:#00} List result = colQry.select(context);{color}
> {color:#00} assertEquals(20, result.size());{color}
>
> {color:#00} {color}{color:#3f7f5f}// Next line fails with
> UnsupportedOperationException{color}
> {color:#00} List result2 = colQry.select(context);{color}
> {color:#00} assertEquals(20, result.size());{color}
> {color:#00} }{color}
>
> Stacktrace:
>
> {color:#ff}Exception in thread "JavaFX Application Thread"
> {color}{color:#0066cc}java.lang.UnsupportedOperationException{color}
> {color:#ff} at
> java.base/java.util.Collections$UnmodifiableCollection.removeIf({color}{color:#0066cc}Collections.java:1120{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction$MixedConversionStrategy.convert({color}{color:#0066cc}DataDomainQueryAction.java:818{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction.interceptObjectConversion({color}{color:#0066cc}DataDomainQueryAction.java:507{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction.execute({color}{color:#0066cc}DataDomainQueryAction.java:135{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain.onQueryNoFilters({color}{color:#0066cc}DataDomain.java:570{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain$DataDomainQueryFilterChain.onQuery({color}{color:#0066cc}DataDomain.java:819{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain.onQuery({color}{color:#0066cc}DataDomain.java:562{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.runQuery({color}{color:#0066cc}ObjectContextQueryAction.java:406{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.executePostCache({color}{color:#0066cc}ObjectContextQueryAction.java:107{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.execute({color}{color:#0066cc}ObjectContextQueryAction.java:94{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataContext.onQuery({color}{color:#0066cc}DataContext.java:960{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataContext.performQuery({color}{color:#0066cc}DataContext.java:949{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.BaseContext.select({color}{color:#0066cc}BaseContext.java:307{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.query.FluentSelect.select({color}{color:#0066cc}FluentSelect.java:160{color}{color:#ff}){color}
>
> Workaround: Add
> {color:#00}{color:#00}.suppressDistinct(){color}{color} to the query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2841) Multi column ColumnSelect with SHARED_CACHE fails after 1st select
[
https://issues.apache.org/jira/browse/CAY-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2841:
-
Fix Version/s: 4.2.1
(was: 4.1.2)
> Multi column ColumnSelect with SHARED_CACHE fails after 1st select
> --
>
> Key: CAY-2841
> URL: https://issues.apache.org/jira/browse/CAY-2841
> Project: Cayenne
> Issue Type: Bug
>Affects Versions: 4.2
>Reporter: Jurgen Doll
>Priority: Minor
> Fix For: 4.2.1, 5.0-M1
>
>
> Adding the following test case to
> {color:#00}{color:#00}ColumnSelectIT{color}{color} shows the problem:
>
> {color:#00} {color}{color:#646464}@{color}{color:#00}Test{color}
> {color:#00} {color}{color:#7f0055}public{color}{color:#00}
> {color}{color:#7f0055}void{color}{color:#00} testSharedCache()
> {color}{color:#7f0055}throws{color}{color:#00} Exception {{color}
> {color:#00} ColumnSelect colQry = ObjectSelect.query(
> Artist.{color}{color:#7f0055}class{color}{color:#00} ){color}
> {color:#00} .columns( Artist.ARTIST_NAME, Artist.DATE_OF_BIRTH ){color}
> {color:#00} .cacheStrategy( QueryCacheStrategy.SHARED_CACHE );{color}
> {color:#00} {color}
> {color:#00} List result = colQry.select(context);{color}
> {color:#00} assertEquals(20, result.size());{color}
>
> {color:#00} {color}{color:#3f7f5f}// Next line fails with
> UnsupportedOperationException{color}
> {color:#00} List result2 = colQry.select(context);{color}
> {color:#00} assertEquals(20, result.size());{color}
> {color:#00} }{color}
>
> Stacktrace:
>
> {color:#ff}Exception in thread "JavaFX Application Thread"
> {color}{color:#0066cc}java.lang.UnsupportedOperationException{color}
> {color:#ff} at
> java.base/java.util.Collections$UnmodifiableCollection.removeIf({color}{color:#0066cc}Collections.java:1120{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction$MixedConversionStrategy.convert({color}{color:#0066cc}DataDomainQueryAction.java:818{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction.interceptObjectConversion({color}{color:#0066cc}DataDomainQueryAction.java:507{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction.execute({color}{color:#0066cc}DataDomainQueryAction.java:135{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain.onQueryNoFilters({color}{color:#0066cc}DataDomain.java:570{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain$DataDomainQueryFilterChain.onQuery({color}{color:#0066cc}DataDomain.java:819{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain.onQuery({color}{color:#0066cc}DataDomain.java:562{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.runQuery({color}{color:#0066cc}ObjectContextQueryAction.java:406{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.executePostCache({color}{color:#0066cc}ObjectContextQueryAction.java:107{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.execute({color}{color:#0066cc}ObjectContextQueryAction.java:94{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataContext.onQuery({color}{color:#0066cc}DataContext.java:960{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataContext.performQuery({color}{color:#0066cc}DataContext.java:949{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.BaseContext.select({color}{color:#0066cc}BaseContext.java:307{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.query.FluentSelect.select({color}{color:#0066cc}FluentSelect.java:160{color}{color:#ff}){color}
>
> Workaround: Add
> {color:#00}{color:#00}.suppressDistinct(){color}{color} to the query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2841) Multi column ColumnSelect with SHARED_CACHE fails after 1st select
[
https://issues.apache.org/jira/browse/CAY-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2841:
-
Fix Version/s: 4.1.2
5.0-M1
> Multi column ColumnSelect with SHARED_CACHE fails after 1st select
> --
>
> Key: CAY-2841
> URL: https://issues.apache.org/jira/browse/CAY-2841
> Project: Cayenne
> Issue Type: Bug
>Affects Versions: 4.2
>Reporter: Jurgen Doll
>Priority: Minor
> Fix For: 4.1.2, 5.0-M1
>
>
> Adding the following test case to
> {color:#00}{color:#00}ColumnSelectIT{color}{color} shows the problem:
>
> {color:#00} {color}{color:#646464}@{color}{color:#00}Test{color}
> {color:#00} {color}{color:#7f0055}public{color}{color:#00}
> {color}{color:#7f0055}void{color}{color:#00} testSharedCache()
> {color}{color:#7f0055}throws{color}{color:#00} Exception {{color}
> {color:#00} ColumnSelect colQry = ObjectSelect.query(
> Artist.{color}{color:#7f0055}class{color}{color:#00} ){color}
> {color:#00} .columns( Artist.ARTIST_NAME, Artist.DATE_OF_BIRTH ){color}
> {color:#00} .cacheStrategy( QueryCacheStrategy.SHARED_CACHE );{color}
> {color:#00} {color}
> {color:#00} List result = colQry.select(context);{color}
> {color:#00} assertEquals(20, result.size());{color}
>
> {color:#00} {color}{color:#3f7f5f}// Next line fails with
> UnsupportedOperationException{color}
> {color:#00} List result2 = colQry.select(context);{color}
> {color:#00} assertEquals(20, result.size());{color}
> {color:#00} }{color}
>
> Stacktrace:
>
> {color:#ff}Exception in thread "JavaFX Application Thread"
> {color}{color:#0066cc}java.lang.UnsupportedOperationException{color}
> {color:#ff} at
> java.base/java.util.Collections$UnmodifiableCollection.removeIf({color}{color:#0066cc}Collections.java:1120{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction$MixedConversionStrategy.convert({color}{color:#0066cc}DataDomainQueryAction.java:818{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction.interceptObjectConversion({color}{color:#0066cc}DataDomainQueryAction.java:507{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomainQueryAction.execute({color}{color:#0066cc}DataDomainQueryAction.java:135{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain.onQueryNoFilters({color}{color:#0066cc}DataDomain.java:570{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain$DataDomainQueryFilterChain.onQuery({color}{color:#0066cc}DataDomain.java:819{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataDomain.onQuery({color}{color:#0066cc}DataDomain.java:562{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.runQuery({color}{color:#0066cc}ObjectContextQueryAction.java:406{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.executePostCache({color}{color:#0066cc}ObjectContextQueryAction.java:107{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.util.ObjectContextQueryAction.execute({color}{color:#0066cc}ObjectContextQueryAction.java:94{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataContext.onQuery({color}{color:#0066cc}DataContext.java:960{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.access.DataContext.performQuery({color}{color:#0066cc}DataContext.java:949{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.BaseContext.select({color}{color:#0066cc}BaseContext.java:307{color}{color:#ff}){color}
> {color:#ff} at
> org.apache.cayenne.query.FluentSelect.select({color}{color:#0066cc}FluentSelect.java:160{color}{color:#ff}){color}
>
> Workaround: Add
> {color:#00}{color:#00}.suppressDistinct(){color}{color} to the query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2840) Vertical Inheritance: Missing subclass attributes with joint prefetch
[ https://issues.apache.org/jira/browse/CAY-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev closed CAY-2840. Assignee: Nikita Timofeev Resolution: Fixed [~jhansell] thank you for reporting this and even more for a fix! Backported fix for *4.2*: https://github.com/apache/cayenne/commit/105a8e2bc9b60a5b0db37191dc70a4a898d58120 > Vertical Inheritance: Missing subclass attributes with joint prefetch > - > > Key: CAY-2840 > URL: https://issues.apache.org/jira/browse/CAY-2840 > Project: Cayenne > Issue Type: Bug > Components: Core Library >Affects Versions: 4.2, 5.0-M1 >Reporter: Jadon Hansell >Assignee: Nikita Timofeev >Priority: Major > Fix For: 4.2.1, 5.0-M1 > > Time Spent: 20m > Remaining Estimate: 0h > > If you use a joint prefetch on a belongs-to relationship whose target is > using vertical inheritance, the attributes on the child class are set to null > instead of using the results from the database. > It looks like this is happening when the attribute is read in > DescriptorColumnExtractor.visitAttribute, it includes the 'p:' prefetch > prefix in the data row key that gets built. Later, the data row result is > read from a map without the prefix in the key, and is not found. This only > happens on a joint prefetch, disjoint and disjointById work correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2840) Vertical Inheritance: Missing subclass attributes with joint prefetch
[ https://issues.apache.org/jira/browse/CAY-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev updated CAY-2840: - Fix Version/s: 4.2.1 5.0-M1 > Vertical Inheritance: Missing subclass attributes with joint prefetch > - > > Key: CAY-2840 > URL: https://issues.apache.org/jira/browse/CAY-2840 > Project: Cayenne > Issue Type: Bug > Components: Core Library >Affects Versions: 4.2, 5.0-M1 >Reporter: Jadon Hansell >Priority: Major > Fix For: 4.2.1, 5.0-M1 > > Time Spent: 10m > Remaining Estimate: 0h > > If you use a joint prefetch on a belongs-to relationship whose target is > using vertical inheritance, the attributes on the child class are set to null > instead of using the results from the database. > It looks like this is happening when the attribute is read in > DescriptorColumnExtractor.visitAttribute, it includes the 'p:' prefetch > prefix in the data row key that gets built. Later, the data row result is > read from a map without the prefix in the key, and is not found. This only > happens on a joint prefetch, disjoint and disjointById work correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAY-2838) Vertical Inheritance: Problem setting db attribute to null via flattened path
[
https://issues.apache.org/jira/browse/CAY-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811319#comment-17811319
]
Nikita Timofeev commented on CAY-2838:
--
Created [PR|https://github.com/apache/cayenne/pull/602] with a simple fix. Not
sure it's correct but all tests are passing.
> Vertical Inheritance: Problem setting db attribute to null via flattened path
> -
>
> Key: CAY-2838
> URL: https://issues.apache.org/jira/browse/CAY-2838
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.2
> Environment: Cayenne 4.2, Java 17, MacOS 14
>Reporter: Jadon Hansell
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Attachments: NullifyFlattenedTests.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While using vertical inheritance, I ran into a bug with a non-required
> attribute on a child {{{}DbEntity{}}}. The issue occurs when an attribute,
> accessed via a flattened path like '{{{}child.attr{}}}' on the child's
> {{{}ObjEntity{}}}, is initially set to a value and then later changed to
> null. This causes Cayenne to attempt to set the primary key of the {{child}}
> db entity to null as well.
> I've attached a patch that contains failing tests demonstrating this issue on
> both an ObjEntity's attribute and a belongs-to relationship.
> A temporary workaround I've used is to relocate these columns to the parent
> DbEntity so the path isn't flattened.
>
> The root of the problem appears to start in the
> {{{}ValuesCreationHandler{}}}. During the operation, it runs
> {{processFlattenedPath}} to identify the target row's ID, with
> {{{}add=false{}}}. This then iterates through the db path components and
> invokes {{processRelationship}} for each db relationship, again with
> {{{}add=false{}}}.
> While processing the first path component, {{processRelationship}} creates an
> {{UPDATE}} row operation, attempting to update the child's uuid to its
> current value (case 2 in the comments). Normally, this would not cause an
> error. But, because the '{{{}add'{}}} parameter is set to false, the
> {{ValuePropagationVisitor}} replaces the current ID with null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAY-2838) Vertical Inheritance: Problem setting db attribute to null via flattened path
[
https://issues.apache.org/jira/browse/CAY-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev reassigned CAY-2838:
Assignee: Nikita Timofeev
> Vertical Inheritance: Problem setting db attribute to null via flattened path
> -
>
> Key: CAY-2838
> URL: https://issues.apache.org/jira/browse/CAY-2838
> Project: Cayenne
> Issue Type: Bug
>Affects Versions: 4.2
> Environment: Cayenne 4.2, Java 17, MacOS 14
>Reporter: Jadon Hansell
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Attachments: NullifyFlattenedTests.patch
>
>
> While using vertical inheritance, I ran into a bug with a non-required
> attribute on a child {{{}DbEntity{}}}. The issue occurs when an attribute,
> accessed via a flattened path like '{{{}child.attr{}}}' on the child's
> {{{}ObjEntity{}}}, is initially set to a value and then later changed to
> null. This causes Cayenne to attempt to set the primary key of the {{child}}
> db entity to null as well.
> I've attached a patch that contains failing tests demonstrating this issue on
> both an ObjEntity's attribute and a belongs-to relationship.
> A temporary workaround I've used is to relocate these columns to the parent
> DbEntity so the path isn't flattened.
>
> The root of the problem appears to start in the
> {{{}ValuesCreationHandler{}}}. During the operation, it runs
> {{processFlattenedPath}} to identify the target row's ID, with
> {{{}add=false{}}}. This then iterates through the db path components and
> invokes {{processRelationship}} for each db relationship, again with
> {{{}add=false{}}}.
> While processing the first path component, {{processRelationship}} creates an
> {{UPDATE}} row operation, attempting to update the child's uuid to its
> current value (case 2 in the comments). Normally, this would not cause an
> error. But, because the '{{{}add'{}}} parameter is set to false, the
> {{ValuePropagationVisitor}} replaces the current ID with null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2838) Vertical Inheritance: Problem setting db attribute to null via flattened path
[
https://issues.apache.org/jira/browse/CAY-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2838:
-
Component/s: Core Library
> Vertical Inheritance: Problem setting db attribute to null via flattened path
> -
>
> Key: CAY-2838
> URL: https://issues.apache.org/jira/browse/CAY-2838
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.2
> Environment: Cayenne 4.2, Java 17, MacOS 14
>Reporter: Jadon Hansell
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Attachments: NullifyFlattenedTests.patch
>
>
> While using vertical inheritance, I ran into a bug with a non-required
> attribute on a child {{{}DbEntity{}}}. The issue occurs when an attribute,
> accessed via a flattened path like '{{{}child.attr{}}}' on the child's
> {{{}ObjEntity{}}}, is initially set to a value and then later changed to
> null. This causes Cayenne to attempt to set the primary key of the {{child}}
> db entity to null as well.
> I've attached a patch that contains failing tests demonstrating this issue on
> both an ObjEntity's attribute and a belongs-to relationship.
> A temporary workaround I've used is to relocate these columns to the parent
> DbEntity so the path isn't flattened.
>
> The root of the problem appears to start in the
> {{{}ValuesCreationHandler{}}}. During the operation, it runs
> {{processFlattenedPath}} to identify the target row's ID, with
> {{{}add=false{}}}. This then iterates through the db path components and
> invokes {{processRelationship}} for each db relationship, again with
> {{{}add=false{}}}.
> While processing the first path component, {{processRelationship}} creates an
> {{UPDATE}} row operation, attempting to update the child's uuid to its
> current value (case 2 in the comments). Normally, this would not cause an
> error. But, because the '{{{}add'{}}} parameter is set to false, the
> {{ValuePropagationVisitor}} replaces the current ID with null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2838) Vertical Inheritance: Problem setting db attribute to null via flattened path
[
https://issues.apache.org/jira/browse/CAY-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2838:
-
Fix Version/s: 4.2.1
5.0-M1
> Vertical Inheritance: Problem setting db attribute to null via flattened path
> -
>
> Key: CAY-2838
> URL: https://issues.apache.org/jira/browse/CAY-2838
> Project: Cayenne
> Issue Type: Bug
>Affects Versions: 4.2
> Environment: Cayenne 4.2, Java 17, MacOS 14
>Reporter: Jadon Hansell
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Attachments: NullifyFlattenedTests.patch
>
>
> While using vertical inheritance, I ran into a bug with a non-required
> attribute on a child {{{}DbEntity{}}}. The issue occurs when an attribute,
> accessed via a flattened path like '{{{}child.attr{}}}' on the child's
> {{{}ObjEntity{}}}, is initially set to a value and then later changed to
> null. This causes Cayenne to attempt to set the primary key of the {{child}}
> db entity to null as well.
> I've attached a patch that contains failing tests demonstrating this issue on
> both an ObjEntity's attribute and a belongs-to relationship.
> A temporary workaround I've used is to relocate these columns to the parent
> DbEntity so the path isn't flattened.
>
> The root of the problem appears to start in the
> {{{}ValuesCreationHandler{}}}. During the operation, it runs
> {{processFlattenedPath}} to identify the target row's ID, with
> {{{}add=false{}}}. This then iterates through the db path components and
> invokes {{processRelationship}} for each db relationship, again with
> {{{}add=false{}}}.
> While processing the first path component, {{processRelationship}} creates an
> {{UPDATE}} row operation, attempting to update the child's uuid to its
> current value (case 2 in the comments). Normally, this would not cause an
> error. But, because the '{{{}add'{}}} parameter is set to false, the
> {{ValuePropagationVisitor}} replaces the current ID with null.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2837) Deprecate TraversalHelper and move no-op implementations to TraversalHandler
[
https://issues.apache.org/jira/browse/CAY-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2837.
Resolution: Fixed
https://github.com/apache/cayenne/commit/d43d29123b4b53e8bf00619183b368d0ba57cc40
> Deprecate TraversalHelper and move no-op implementations to TraversalHandler
>
>
> Key: CAY-2837
> URL: https://issues.apache.org/jira/browse/CAY-2837
> Project: Cayenne
> Issue Type: Improvement
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Trivial
> Fix For: 5.0-M1
>
>
> This is just a minor code cleanup, since we could have default
> implementations in the interface directly, we could just drop
> {{TraversalHelper}} completely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2837) Deprecate TraversalHelper and move no-op implementations to TraversalHandler
[
https://issues.apache.org/jira/browse/CAY-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2837:
-
Summary: Deprecate TraversalHelper and move no-op implementations to
TraversalHandler (was: Depracate TraversalHelper and move no-op
implementations to TraversalHandler)
> Deprecate TraversalHelper and move no-op implementations to TraversalHandler
>
>
> Key: CAY-2837
> URL: https://issues.apache.org/jira/browse/CAY-2837
> Project: Cayenne
> Issue Type: Improvement
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Trivial
> Fix For: 5.0-M1
>
>
> This is just a minor code cleanup, since we could have default
> implementations in the interface directly, we could just drop
> {{TraversalHelper}} completely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2837) Depracate TraversalHelper and move no-op implementations to TraversalHandler
Nikita Timofeev created CAY-2837:
Summary: Depracate TraversalHelper and move no-op implementations
to TraversalHandler
Key: CAY-2837
URL: https://issues.apache.org/jira/browse/CAY-2837
Project: Cayenne
Issue Type: Improvement
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 5.0-M1
This is just a minor code cleanup, since we could have default implementations
in the interface directly, we could just drop {{TraversalHelper}} completely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAY-2814) Select query iterator() and batchIterator() methods return incorrect results
[
https://issues.apache.org/jira/browse/CAY-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809470#comment-17809470
]
Nikita Timofeev commented on CAY-2814:
--
{*}5.0{*}:
[https://github.com/apache/cayenne/commit/3438ed9ffb30591e6661b55e61c1ba9d457acc66]
+ follow-up commits
> Select query iterator() and batchIterator() methods return incorrect results
>
>
> Key: CAY-2814
> URL: https://issues.apache.org/jira/browse/CAY-2814
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.1.1, 4.2.RC1, 4.2
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Iterated queries can handle only basic results like single entity,
> {{Object[]}} and {{DataRow}}
> everything else is missing in the processing.
> This affects ColumnQuery most as it can return many more variants.
> What variants are broken:
> * all selects: joint prefetches
> * column query: several entities or entity + some other fields
> * column query: embeddables
> * column query: map function (see CAY-2812)
> * maybe something else (?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2805) Stop calling exp parser internally
[ https://issues.apache.org/jira/browse/CAY-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev updated CAY-2805: - Fix Version/s: 5.0-M1 4.2 > Stop calling exp parser internally > -- > > Key: CAY-2805 > URL: https://issues.apache.org/jira/browse/CAY-2805 > Project: Cayenne > Issue Type: Improvement >Affects Versions: 4.2.RC2 >Reporter: Andrus Adamchik >Assignee: Nikita Timofeev >Priority: Minor > Fix For: 4.2, 5.0-M1 > > > This is a performance optimization suggestion. Just noticed during profiling > a few minor "hotspots" due to calling "ExpressionFactory.exp()" inside the > following methods in the Cayenne core: > * PrefetchProcessorJointNode.buildRowMapping(..) > * DefaultSelectTranslator.appendQueryColumns(..) > * SelectQueryMetadata.buildEntityResultForColumn(..) > This results in exp parser invocation, which is fairly slow. At the same > time, in all these places the expression is known to be a path (either DB or > OBJ). So we can take a shortcut and apply a faster parsing function to > generate ASTObjPath or ASTDbPath. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAY-2806) Incorrect processing of unicode escape syntax in JSON
[
https://issues.apache.org/jira/browse/CAY-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2806.
Resolution: Fixed
> Incorrect processing of unicode escape syntax in JSON
> -
>
> Key: CAY-2806
> URL: https://issues.apache.org/jira/browse/CAY-2806
> Project: Cayenne
> Issue Type: Bug
>Affects Versions: 4.2
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0-M1
>
>
> Internal JSON parser can't handle Unicode escape syntax like {{\u0123}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2808) Modeler 4.1.1 can't save on Windows
[
https://issues.apache.org/jira/browse/CAY-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2808.
Resolution: Fixed
https://github.com/apache/cayenne/commit/8aaba91f13c4da5984845d0db4041cc28b7283a7
> Modeler 4.1.1 can't save on Windows
> ---
>
> Key: CAY-2808
> URL: https://issues.apache.org/jira/browse/CAY-2808
> Project: Cayenne
> Issue Type: Bug
> Components: cgen, Modeler
>Affects Versions: 4.1.1
>Reporter: Andrus Adamchik
>Assignee: Nikita Timofeev
>Priority: Minor
> Fix For: 4.1.2
>
>
> Windows 11 pro, Java 11 , Cayenne Modeler 4.1.1. When trying to save a simple
> new project (a new project + a single empty DataMap), the following the
> Modeler throws this exception. CM 4.1 and 4.2 work correctly on the same
> machine.
> {noformat}
> CayenneModeler Info
> Version: 4.1.1
> Build Date: Dec 20 2021 17:17:41
> Exception:
> =
> java.lang.IllegalArgumentException: 'other' has different root
> at java.base/sun.nio.fs.WindowsPath.relativize(WindowsPath.java:404)
> at java.base/sun.nio.fs.WindowsPath.relativize(WindowsPath.java:42)
> at
> org.apache.cayenne.gen.xml.CgenSaverDelegate.resolveOutputDir(CgenSaverDelegate.java:75)
> at
> org.apache.cayenne.gen.xml.CgenSaverDelegate.visitDataMap(CgenSaverDelegate.java:48)
> at
> org.apache.cayenne.gen.xml.CgenSaverDelegate.visitDataMap(CgenSaverDelegate.java:36)
> at
> org.apache.cayenne.project.CompoundSaverDelegate.visitDataMap(CompoundSaverDelegate.java:73)
> at
> org.apache.cayenne.project.CompoundSaverDelegate.visitDataMap(CompoundSaverDelegate.java:45)
> at org.apache.cayenne.map.DataMap.encodeAsXML(DataMap.java:332)
> at
> org.apache.cayenne.project.ConfigurationSaver.encodeNode(ConfigurationSaver.java:61)
> at
> org.apache.cayenne.project.ConfigurationSaver.visitDataMap(ConfigurationSaver.java:53)
> at
> org.apache.cayenne.project.ConfigurationSaver.visitDataMap(ConfigurationSaver.java:33)
> at org.apache.cayenne.map.DataMap.acceptVisitor(DataMap.java:200)
> at
> org.apache.cayenne.project.FileProjectSaver.saveToTempFile(FileProjectSaver.java:241)
> at
> org.apache.cayenne.project.FileProjectSaver.saveToTempFiles(FileProjectSaver.java:220)
> at
> org.apache.cayenne.project.FileProjectSaver.save(FileProjectSaver.java:122)
> at
> org.apache.cayenne.project.FileProjectSaver.saveAs(FileProjectSaver.java:93)
> at
> org.apache.cayenne.modeler.action.SaveAsAction.saveAll(SaveAsAction.java:106)
> at
> org.apache.cayenne.modeler.action.SaveAction.saveAll(SaveAction.java:60)
> at
> org.apache.cayenne.modeler.action.SaveAsAction.performAction(SaveAsAction.java:166)
> at
> org.apache.cayenne.modeler.action.SaveAsAction.performAction(SaveAsAction.java:155)
> at
> org.apache.cayenne.modeler.util.CayenneAction.actionPerformed(CayenneAction.java:171)
> at
> java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967)
> at
> java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2308)
> at
> java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
> at
> java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
> at
> java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:279)
> at
> java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
> at
> java.desktop/java.awt.Component.processMouseEvent(Component.java:6635)
> at
> java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342)
> at java.desktop/java.awt.Component.processEvent(Component.java:6400)
> at java.desktop/java.awt.Container.processEvent(Container.java:2263)
> at
> java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5011)
> at
> java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4843)
> at
> java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918)
> at
> java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4547)
> at
> java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488)
> at
> java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307)
> at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4843)
> at
> java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
> at
[jira] [Closed] (CAY-2820) Remove `server` from the components naming
[
https://issues.apache.org/jira/browse/CAY-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2820.
Resolution: Fixed
> Remove `server` from the components naming
> --
>
> Key: CAY-2820
> URL: https://issues.apache.org/jira/browse/CAY-2820
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Labels: incompatible
> Fix For: 5.0-M1
>
>
> there's no reason for {{server}} to stay after ROP is gone and we don't have
> any {{client}} counterparts.
> Here are the most sensitive parts that will likely change as part of this
> task:
> * {{cayenne-server}} module
> * {{ServerRuntime}} and {{ServerRuntimeBuilder}}
> * {{ServerModule}} and it's extender
> * {{CayenneServerModuleProvider}} that backs module autoloading feature
> * {{org.apache.cayenne.configuration.server}} package
> There are separate sub-tasks for these items, everything else will go with
> reference to this task directly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2811) Incorrect SQL building using ColumnQuery with ASTScalar
[
https://issues.apache.org/jira/browse/CAY-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2811.
Resolution: Fixed
https://github.com/apache/cayenne/commit/605785b24ff025075b998b90707149f03dffd02a
> Incorrect SQL building using ColumnQuery with ASTScalar
> ---
>
> Key: CAY-2811
> URL: https://issues.apache.org/jira/browse/CAY-2811
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.1, 4.2
>Reporter: Ivan Nikitka
>Priority: Major
> Fix For: 5.0-M1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *The resulted SQL of*
> Property property =
> Property.create(ExpressionFactory.wrapScalarValue(123), Integer.class);
> ObjectSelect.columnQuery(Artist.class, Artist.ARTIST_NAME,
> property).select(context);
> *is:*
> {color:#FF}java.sql.SQLSyntaxErrorException: unexpected token: FROM in
> statement [SELECT RTRIM(t0.ARTIST_NAME), FROM ARTIST t0]{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2811) Incorrect SQL building using ColumnQuery with ASTScalar
[
https://issues.apache.org/jira/browse/CAY-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2811:
-
Summary: Incorrect SQL building using ColumnQuery with ASTScalar (was:
Incorrect SQL building using ColumnQuerry with ASTScalar)
> Incorrect SQL building using ColumnQuery with ASTScalar
> ---
>
> Key: CAY-2811
> URL: https://issues.apache.org/jira/browse/CAY-2811
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.1, 4.2
>Reporter: Ivan Nikitka
>Priority: Major
> Fix For: 5.0-M1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *The resulted SQL of*
> Property property =
> Property.create(ExpressionFactory.wrapScalarValue(123), Integer.class);
> ObjectSelect.columnQuery(Artist.class, Artist.ARTIST_NAME,
> property).select(context);
> *is:*
> {color:#FF}java.sql.SQLSyntaxErrorException: unexpected token: FROM in
> statement [SELECT RTRIM(t0.ARTIST_NAME), FROM ARTIST t0]{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2815) Incorrect translation of aliased expression
[ https://issues.apache.org/jira/browse/CAY-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev closed CAY-2815. Resolution: Fixed *5.0* - https://github.com/apache/cayenne/commit/5f5b304ffce8c3e95d23c1f65c861d7365433ad8 *4.2* - https://github.com/apache/cayenne/commit/e57d6a3b08965b06869bab64e513b228cbc00674 > Incorrect translation of aliased expression > --- > > Key: CAY-2815 > URL: https://issues.apache.org/jira/browse/CAY-2815 > Project: Cayenne > Issue Type: Bug > Components: Database integration >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 4.2.1, 5.0-M1 > > > Fix for CAY-2810 brake SQL generation for some expressions with alias. For > instance it breaks subquery that is used for LIMIT/OFFSET on Oracle DB. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2835) Custom aggregate functions
Nikita Timofeev created CAY-2835: Summary: Custom aggregate functions Key: CAY-2835 URL: https://issues.apache.org/jira/browse/CAY-2835 Project: Cayenne Issue Type: Improvement Components: Core Library Reporter: Nikita Timofeev Assignee: Nikita Timofeev Fix For: 5.0-M1 We already have support for custom SQL operators and functions, but there's no easy way to use custom aggregate functions. See also this thread: https://lists.apache.org/thread/hqwm68200m7od24zzvypmxq84fdp6y9q -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2820) Remove `server` from the components naming
[
https://issues.apache.org/jira/browse/CAY-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2820:
-
Labels: incompatible (was: )
> Remove `server` from the components naming
> --
>
> Key: CAY-2820
> URL: https://issues.apache.org/jira/browse/CAY-2820
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Labels: incompatible
> Fix For: 5.0-M1
>
>
> there's no reason for {{server}} to stay after ROP is gone and we don't have
> any {{client}} counterparts.
> Here are the most sensitive parts that will likely change as part of this
> task:
> * {{cayenne-server}} module
> * {{ServerRuntime}} and {{ServerRuntimeBuilder}}
> * {{ServerModule}} and it's extender
> * {{CayenneServerModuleProvider}} that backs module autoloading feature
> * {{org.apache.cayenne.configuration.server}} package
> There are separate sub-tasks for these items, everything else will go with
> reference to this task directly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAY-2834) v11 upgrade handler should update XMLPoolingDataSourceFactory package
[ https://issues.apache.org/jira/browse/CAY-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev reassigned CAY-2834: Assignee: Nikita Timofeev > v11 upgrade handler should update XMLPoolingDataSourceFactory package > - > > Key: CAY-2834 > URL: https://issues.apache.org/jira/browse/CAY-2834 > Project: Cayenne > Issue Type: Sub-task > Components: Modeler >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 5.0-M1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAY-2834) v11 upgrade handler should update XMLPoolingDataSourceFactory package
[ https://issues.apache.org/jira/browse/CAY-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev closed CAY-2834. Resolution: Fixed https://github.com/apache/cayenne/commit/3405e7f79dc65436a96be87ff6d05cf3c95155ec > v11 upgrade handler should update XMLPoolingDataSourceFactory package > - > > Key: CAY-2834 > URL: https://issues.apache.org/jira/browse/CAY-2834 > Project: Cayenne > Issue Type: Sub-task > Components: Modeler >Reporter: Nikita Timofeev >Priority: Major > Fix For: 5.0-M1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2834) v11 upgrade handler should update XMLPoolingDataSourceFactory package
Nikita Timofeev created CAY-2834: Summary: v11 upgrade handler should update XMLPoolingDataSourceFactory package Key: CAY-2834 URL: https://issues.apache.org/jira/browse/CAY-2834 Project: Cayenne Issue Type: Sub-task Components: Modeler Reporter: Nikita Timofeev Fix For: 5.0-M1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2833) Unify code related to the Cayenne model paths processing
Nikita Timofeev created CAY-2833:
Summary: Unify code related to the Cayenne model paths processing
Key: CAY-2833
URL: https://issues.apache.org/jira/browse/CAY-2833
Project: Cayenne
Issue Type: Improvement
Components: Core Library
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 5.0-M1
Main idea of this task is to unify and possibly optimize all path-related logic
in the Cayenne core.
Over the years we got many places in the code that are working with paths and
often it's just some sort of in-place solutions. So we definitely can do much
better.
The first idea is to introduce {{CayennePath}} object and try to use it instead
of a plain {{String}} that is parsed and/or concatenated many times.
Ultimate goal is to use this object everywhere in the Core, including:
* expression API
* property API
* query translators
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2832) SelectActionIT is failing on GitHub Actions
Nikita Timofeev created CAY-2832:
Summary: SelectActionIT is failing on GitHub Actions
Key: CAY-2832
URL: https://issues.apache.org/jira/browse/CAY-2832
Project: Cayenne
Issue Type: Bug
Reporter: Nikita Timofeev
Fix For: 5.0-M1
{{SelectActionIT}} test is failing on GitHub Actions for H2, HSQL and Derby
with no apparent reason. Started with this commit
https://github.com/apache/cayenne/actions/runs/7128786333 and persisted until I
turned this test off.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAY-2818) JDK 21 support
[ https://issues.apache.org/jira/browse/CAY-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795309#comment-17795309 ] Nikita Timofeev edited comment on CAY-2818 at 12/11/23 11:51 AM: - Modeler builds and runs on Java 21, so closing this. was (Author: ntimofeev): Modeler builds and runs in Java 21, so closing this. > JDK 21 support > -- > > Key: CAY-2818 > URL: https://issues.apache.org/jira/browse/CAY-2818 > Project: Cayenne > Issue Type: Task >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 5.0-M1 > > > JDK 21 is LTS so we need to support it. As always main blocker right now is > Gradle that is [lacking > support|https://docs.gradle.org/current/userguide/compatibility.html] for > Java 21. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAY-2818) JDK 21 support
[ https://issues.apache.org/jira/browse/CAY-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev closed CAY-2818. Resolution: Fixed Modeler builds and runs in Java 21, so closing this. > JDK 21 support > -- > > Key: CAY-2818 > URL: https://issues.apache.org/jira/browse/CAY-2818 > Project: Cayenne > Issue Type: Task >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 5.0-M1 > > > JDK 21 is LTS so we need to support it. As always main blocker right now is > Gradle that is [lacking > support|https://docs.gradle.org/current/userguide/compatibility.html] for > Java 21. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAY-2817) Pagination flow refactoring
[
https://issues.apache.org/jira/browse/CAY-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2817.
Resolution: Fixed
https://github.com/apache/cayenne/commit/b487051586e5f7859a92e735c5f5b0b6d3a11f74
> Pagination flow refactoring
> ---
>
> Key: CAY-2817
> URL: https://issues.apache.org/jira/browse/CAY-2817
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Affects Versions: 5.0-M1
>Reporter: Ivan Nikitka
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
>
> The current process for pagination uses direct method for gathering data.
> Without any checks, validations and convertations.
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator performIteratedQuery(Query query)
> }{code}
> {code:java}
> public class IncrementalFaultList implements List, Serializable {
> ...
> protected void fillIn(final Query query, List elementsList) {
>elementsList.clear();
>try (ResultIterator it = dataContext.performIteratedQuery(query)) {
> while (it.hasNextRow()) {
> elementsList.add(it.nextRow());
> }
>}
>unfetchedObjects = elementsList.size();
> }{code}
> After applying [this|https://github.com/apache/cayenne/pull/594/] PR we need
> to redirect pagination flow to the
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator iterator(final Select query)
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2819) DataContext.performIteratedQuery() method should be unified with iterator() method
[ https://issues.apache.org/jira/browse/CAY-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev closed CAY-2819. Resolution: Fixed https://github.com/apache/cayenne/commit/b72b1f4f8be3ee22e09ae4300ff696af6081adf6 > DataContext.performIteratedQuery() method should be unified with iterator() > method > -- > > Key: CAY-2819 > URL: https://issues.apache.org/jira/browse/CAY-2819 > Project: Cayenne > Issue Type: Task > Components: Core Library >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Minor > Fix For: 5.0-M1 > > > This one should be a part of CAY-2814, but it's blocked by CAY-2817. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAY-2831) Upgrade Gradle to 8.5
[ https://issues.apache.org/jira/browse/CAY-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev closed CAY-2831. Resolution: Fixed > Upgrade Gradle to 8.5 > - > > Key: CAY-2831 > URL: https://issues.apache.org/jira/browse/CAY-2831 > Project: Cayenne > Issue Type: Task > Components: Non-GUI Tools >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 5.0-M1 > > > Gradle 8.5 is out and it'll bring support for Java 21. This will probably > also solve CAY-2818. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2831) Upgrade Gradle to 8.5
Nikita Timofeev created CAY-2831: Summary: Upgrade Gradle to 8.5 Key: CAY-2831 URL: https://issues.apache.org/jira/browse/CAY-2831 Project: Cayenne Issue Type: Task Components: Non-GUI Tools Reporter: Nikita Timofeev Assignee: Nikita Timofeev Fix For: 5.0-M1 Gradle 8.5 is out and it'll bring support for Java 21. This will probably also solve CAY-2818. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAY-2830) Cleanup DataContext code
[
https://issues.apache.org/jira/browse/CAY-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2830.
Resolution: Fixed
> Cleanup DataContext code
>
>
> Key: CAY-2830
> URL: https://issues.apache.org/jira/browse/CAY-2830
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
>
> After CAY-2829 is done {{DataContext}} class became huge (not that it was
> tiny before). We need to trim it a bit to keep somewhat manageable in the
> future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2830) Cleanup DataContext code
[
https://issues.apache.org/jira/browse/CAY-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2830:
-
Summary: Cleanup DataContext code (was: Cleanup DataContext)
> Cleanup DataContext code
>
>
> Key: CAY-2830
> URL: https://issues.apache.org/jira/browse/CAY-2830
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
>
> After CAY-2829 is done {{DataContext}} class became huge (not that it was
> tiny before). We need to trim it a bit to keep somewhat manageable in the
> future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2830) Cleanup DataContext
Nikita Timofeev created CAY-2830:
Summary: Cleanup DataContext
Key: CAY-2830
URL: https://issues.apache.org/jira/browse/CAY-2830
Project: Cayenne
Issue Type: Task
Components: Core Library
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 5.0-M1
After CAY-2829 is done {{DataContext}} class became huge (not that it was tiny
before). We need to trim it a bit to keep somewhat manageable in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2829) Merge BaseContext with DataContext and deprecate it
[
https://issues.apache.org/jira/browse/CAY-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2829.
Resolution: Fixed
https://github.com/apache/cayenne/commit/d8941d1a89a87ad8417831be2c021d3da758ad8f
> Merge BaseContext with DataContext and deprecate it
> ---
>
> Key: CAY-2829
> URL: https://issues.apache.org/jira/browse/CAY-2829
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
>
> This task is about moving all code from {{BaseContext}} to {{DataContext}}.
> No need to keep base context implementation as there's only one type of
> context existing right now. This will also allow to clean implementation up a
> bit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2829) Merge BaseContext with DataContext and deprecate it
Nikita Timofeev created CAY-2829:
Summary: Merge BaseContext with DataContext and deprecate it
Key: CAY-2829
URL: https://issues.apache.org/jira/browse/CAY-2829
Project: Cayenne
Issue Type: Task
Components: Core Library
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 5.0-M1
This task is about moving all code from {{BaseContext}} to {{DataContext}}.
No need to keep base context implementation as there's only one type of context
existing right now. This will also allow to clean implementation up a bit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2828) Rename values in `org.apache.cayenne.configuration.Constants`
[
https://issues.apache.org/jira/browse/CAY-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2828.
Resolution: Fixed
https://github.com/apache/cayenne/commit/64835b483c0333d366c9fd789385d6cc71de122d
> Rename values in `org.apache.cayenne.configuration.Constants`
> -
>
> Key: CAY-2828
> URL: https://issues.apache.org/jira/browse/CAY-2828
> Project: Cayenne
> Issue Type: Sub-task
> Components: Core Library
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
>
> We got a bunch of constants with a {{SERVER_}} prefix, need to rename those.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2828) Rename values in `org.apache.cayenne.configuration.Constants`
Nikita Timofeev created CAY-2828:
Summary: Rename values in
`org.apache.cayenne.configuration.Constants`
Key: CAY-2828
URL: https://issues.apache.org/jira/browse/CAY-2828
Project: Cayenne
Issue Type: Sub-task
Components: Core Library
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 5.0-M1
We got a bunch of constants with a {{SERVER_}} prefix, need to rename those.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2827) Saved data-source XML data doesn't correspond to the XSD schema
[
https://issues.apache.org/jira/browse/CAY-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2827:
-
Affects Version/s: (was: 4.2)
> Saved data-source XML data doesn't correspond to the XSD schema
> ---
>
> Key: CAY-2827
> URL: https://issues.apache.org/jira/browse/CAY-2827
> Project: Cayenne
> Issue Type: Bug
> Components: Modeler
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Minor
> Fix For: 5.0-M1
>
>
> Order of children elements in {{}} tag saved by them Modeler
> doesn't correspond to the {{domain.xsd}} schema.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2825) Rename org.apache.cayenne.configuration.server to org.apache.cayenne.configuration.runtime
[ https://issues.apache.org/jira/browse/CAY-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev closed CAY-2825. Resolution: Fixed https://github.com/apache/cayenne/commit/1f21255979a454a679c9c52dcdb6449b4e892714 > Rename org.apache.cayenne.configuration.server to > org.apache.cayenne.configuration.runtime > -- > > Key: CAY-2825 > URL: https://issues.apache.org/jira/browse/CAY-2825 > Project: Cayenne > Issue Type: Sub-task >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 5.0-M1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAY-2827) Saved data-source XML data doesn't correspond to the XSD schema
[
https://issues.apache.org/jira/browse/CAY-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2827.
Resolution: Fixed
https://github.com/apache/cayenne/commit/78aa381ed60bc137c55a9088af59f81c0cdd8ca5
> Saved data-source XML data doesn't correspond to the XSD schema
> ---
>
> Key: CAY-2827
> URL: https://issues.apache.org/jira/browse/CAY-2827
> Project: Cayenne
> Issue Type: Bug
> Components: Modeler
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Minor
> Fix For: 5.0-M1
>
>
> Order of children elements in {{}} tag saved by them Modeler
> doesn't correspond to the {{domain.xsd}} schema.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2827) Saved data-source XML data doesn't correspond to the XSD schema
[
https://issues.apache.org/jira/browse/CAY-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2827:
-
Fix Version/s: (was: 4.2.1)
> Saved data-source XML data doesn't correspond to the XSD schema
> ---
>
> Key: CAY-2827
> URL: https://issues.apache.org/jira/browse/CAY-2827
> Project: Cayenne
> Issue Type: Bug
> Components: Modeler
>Affects Versions: 4.2
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Minor
> Fix For: 5.0-M1
>
>
> Order of children elements in {{}} tag saved by them Modeler
> doesn't correspond to the {{domain.xsd}} schema.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2827) Saved data-source XML data doesn't correspond to the XSD schema
Nikita Timofeev created CAY-2827:
Summary: Saved data-source XML data doesn't correspond to the XSD
schema
Key: CAY-2827
URL: https://issues.apache.org/jira/browse/CAY-2827
Project: Cayenne
Issue Type: Bug
Components: Modeler
Affects Versions: 4.2
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 4.2.1, 5.0-M1
Order of children elements in {{}} tag saved by them Modeler
doesn't correspond to the {{domain.xsd}} schema.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2825) Rename org.apache.cayenne.configuration.server to org.apache.cayenne.configuration.runtime
[ https://issues.apache.org/jira/browse/CAY-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev updated CAY-2825: - Summary: Rename org.apache.cayenne.configuration.server to org.apache.cayenne.configuration.runtime (was: Rename org.apache.cayenne.configuration.server to org.apache.cayenne.configuration.core) > Rename org.apache.cayenne.configuration.server to > org.apache.cayenne.configuration.runtime > -- > > Key: CAY-2825 > URL: https://issues.apache.org/jira/browse/CAY-2825 > Project: Cayenne > Issue Type: Sub-task >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 5.0-M1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAY-2824) Rename CayenneServerModuleProvider to CayenneRuntimeModuleProvider
[
https://issues.apache.org/jira/browse/CAY-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2824.
Resolution: Fixed
https://github.com/apache/cayenne/commit/9f7ecc4f08ec32d2ff6e7fb480bd865cbcc8d41b
> Rename CayenneServerModuleProvider to CayenneRuntimeModuleProvider
> --
>
> Key: CAY-2824
> URL: https://issues.apache.org/jira/browse/CAY-2824
> Project: Cayenne
> Issue Type: Sub-task
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
>
> This task includes renaming all {{META-INF.services}} references. Also it is
> a breaking change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2824) Rename CayenneServerModuleProvider to CayenneRuntimeModuleProvider
[
https://issues.apache.org/jira/browse/CAY-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2824:
-
Summary: Rename CayenneServerModuleProvider to CayenneRuntimeModuleProvider
(was: Rename CayenneServerModuleProvider to CayenneCoreModuleProvider)
> Rename CayenneServerModuleProvider to CayenneRuntimeModuleProvider
> --
>
> Key: CAY-2824
> URL: https://issues.apache.org/jira/browse/CAY-2824
> Project: Cayenne
> Issue Type: Sub-task
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
>
> This task includes renaming all {{META-INF.services}} references. Also it is
> a breaking change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2826) Rename ServerModule to CoreModule
[
https://issues.apache.org/jira/browse/CAY-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2826.
Resolution: Fixed
https://github.com/apache/cayenne/commit/e8eef1d4dd0e4fcf7b54fea0aa85ab2fdc79a1b2
> Rename ServerModule to CoreModule
> -
>
> Key: CAY-2826
> URL: https://issues.apache.org/jira/browse/CAY-2826
> Project: Cayenne
> Issue Type: Sub-task
> Components: Core Library
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
>
> This also includes renaming of {{ServerModuleExtender}} and
> {{ToolsServerModuleExtender}} classes
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2823) Merge ServerRuntime back to CayenneRuntime and deprecate it
[ https://issues.apache.org/jira/browse/CAY-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev closed CAY-2823. Resolution: Fixed https://github.com/apache/cayenne/commit/d01654e3110dea3dcd06050a081843b2024f0fb0 > Merge ServerRuntime back to CayenneRuntime and deprecate it > --- > > Key: CAY-2823 > URL: https://issues.apache.org/jira/browse/CAY-2823 > Project: Cayenne > Issue Type: Sub-task > Components: Core Library >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 5.0-M1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CAY-2821) Change development versioning schema
[
https://issues.apache.org/jira/browse/CAY-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2821.
Resolution: Fixed
https://github.com/apache/cayenne/commit/1b05343356ac1ed0b736053ce0bb035bfbef020d
> Change development versioning schema
>
>
> Key: CAY-2821
> URL: https://issues.apache.org/jira/browse/CAY-2821
> Project: Cayenne
> Issue Type: Task
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
>
> See [this
> thread|https://lists.apache.org/thread/pwms0ncx8zbt5hfxlpz7yj0gcdwmz9pq] for
> a bit more details.
> Format would look like {{MAJOR.MINOR-QUALIFIER}}. Where the qualifier is one
> of {{SNAPSHOT}}, {{M}} for the milestone or {{RC}} for the release candidate.
>
> Example for the 5.0:
> - snapshot always stays as 5.0-SNAPSHOT
> - milestones releases are 5.0-M1, 5.0-M2 etc.
> - release candidates are 5.0-RC1, 5.0-RC2, etc.
> - and final release is just 5.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2822) Rename `cayenne-server` module to `cayenne`
[ https://issues.apache.org/jira/browse/CAY-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev closed CAY-2822. Resolution: Fixed https://github.com/apache/cayenne/commit/5c408c32f9fa99030d539748546df03dd4a4ed93 > Rename `cayenne-server` module to `cayenne` > --- > > Key: CAY-2822 > URL: https://issues.apache.org/jira/browse/CAY-2822 > Project: Cayenne > Issue Type: Sub-task > Components: Core Library >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 5.0-M1 > > > This task is part of CAY-2820. Moving into a separate one as it a pretty > significant and a breaking change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2820) Remove `server` from the components naming
[
https://issues.apache.org/jira/browse/CAY-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2820:
-
Description:
there's no reason for {{server}} to stay after ROP is gone and we don't have
any {{client}} counterparts.
Here are the most sensitive parts that will likely change as part of this task:
* {{cayenne-server}} module
* {{ServerRuntime}} and {{ServerRuntimeBuilder}}
* {{ServerModule}} and it's extender
* {{CayenneServerModuleProvider}} that backs module autoloading feature
* {{org.apache.cayenne.configuration.server}} package
There are separate sub-tasks for these items, everything else will go with
reference to this task directly.
was:
there's no reason for {{server}} to stay after ROP is gone and we don't have
any {{client}} counterparts.
Here are the most sensitive parts that will likely change as part of this task:
* {{cayenne-server}} module
* {{ServerRuntime}} and {{ServerRuntimeBuilder}}
* {{ServerModule}} and it's extender
* {{CayenneServerModuleProvider}} that backs module autoloading feature
* {{org.apache.cayenne.configuration.server}} package
> Remove `server` from the components naming
> --
>
> Key: CAY-2820
> URL: https://issues.apache.org/jira/browse/CAY-2820
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0-M1
>
>
> there's no reason for {{server}} to stay after ROP is gone and we don't have
> any {{client}} counterparts.
> Here are the most sensitive parts that will likely change as part of this
> task:
> * {{cayenne-server}} module
> * {{ServerRuntime}} and {{ServerRuntimeBuilder}}
> * {{ServerModule}} and it's extender
> * {{CayenneServerModuleProvider}} that backs module autoloading feature
> * {{org.apache.cayenne.configuration.server}} package
> There are separate sub-tasks for these items, everything else will go with
> reference to this task directly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2826) Rename ServerModule to CoreModule
Nikita Timofeev created CAY-2826:
Summary: Rename ServerModule to CoreModule
Key: CAY-2826
URL: https://issues.apache.org/jira/browse/CAY-2826
Project: Cayenne
Issue Type: Sub-task
Components: Core Library
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 5.0-M1
This also includes renaming of {{ServerModuleExtender}} and
{{ToolsServerModuleExtender}} classes
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2825) Rename org.apache.cayenne.configuration.server to org.apache.cayenne.configuration.core
Nikita Timofeev created CAY-2825: Summary: Rename org.apache.cayenne.configuration.server to org.apache.cayenne.configuration.core Key: CAY-2825 URL: https://issues.apache.org/jira/browse/CAY-2825 Project: Cayenne Issue Type: Sub-task Reporter: Nikita Timofeev Assignee: Nikita Timofeev Fix For: 5.0-M1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2824) Rename CayenneServerModuleProvider to CayenneCoreModuleProvider
Nikita Timofeev created CAY-2824:
Summary: Rename CayenneServerModuleProvider to
CayenneCoreModuleProvider
Key: CAY-2824
URL: https://issues.apache.org/jira/browse/CAY-2824
Project: Cayenne
Issue Type: Sub-task
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 5.0-M1
This task includes renaming all {{META-INF.services}} references. Also it is a
breaking change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2823) Merge ServerRuntime back to CayenneRuntime and deprecate it
Nikita Timofeev created CAY-2823: Summary: Merge ServerRuntime back to CayenneRuntime and deprecate it Key: CAY-2823 URL: https://issues.apache.org/jira/browse/CAY-2823 Project: Cayenne Issue Type: Sub-task Components: Core Library Reporter: Nikita Timofeev Assignee: Nikita Timofeev Fix For: 5.0-M1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2822) Rename `cayenne-server` module to `cayenne`
[ https://issues.apache.org/jira/browse/CAY-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Timofeev updated CAY-2822: - Parent: CAY-2820 Issue Type: Sub-task (was: Task) > Rename `cayenne-server` module to `cayenne` > --- > > Key: CAY-2822 > URL: https://issues.apache.org/jira/browse/CAY-2822 > Project: Cayenne > Issue Type: Sub-task > Components: Core Library >Reporter: Nikita Timofeev >Assignee: Nikita Timofeev >Priority: Major > Fix For: 5.0-M1 > > > This task is part of CAY-2820. Moving into a separate one as it a pretty > significant and a breaking change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2822) Rename `cayenne-server` module to `cayenne`
Nikita Timofeev created CAY-2822: Summary: Rename `cayenne-server` module to `cayenne` Key: CAY-2822 URL: https://issues.apache.org/jira/browse/CAY-2822 Project: Cayenne Issue Type: Task Components: Core Library Reporter: Nikita Timofeev Assignee: Nikita Timofeev Fix For: 5.0-M1 This task is part of CAY-2820. Moving into a separate one as it a pretty significant and a breaking change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2821) Change development versioning schema
Nikita Timofeev created CAY-2821:
Summary: Change development versioning schema
Key: CAY-2821
URL: https://issues.apache.org/jira/browse/CAY-2821
Project: Cayenne
Issue Type: Task
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 5.0.M1
See [this
thread|https://lists.apache.org/thread/pwms0ncx8zbt5hfxlpz7yj0gcdwmz9pq] for a
bit more details.
Format would look like {{MAJOR.MINOR-QUALIFIER}}. Where the qualifier is one of
{{SNAPSHOT}}, {{M}} for the milestone or {{RC}} for the release candidate.
Example for the 5.0:
- snapshot always stays as 5.0-SNAPSHOT
- milestones releases are 5.0-M1, 5.0-M2 etc.
- release candidates are 5.0-RC1, 5.0-RC2, etc.
- and final release is just 5.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2820) Remove `server` from the components naming
Nikita Timofeev created CAY-2820:
Summary: Remove `server` from the components naming
Key: CAY-2820
URL: https://issues.apache.org/jira/browse/CAY-2820
Project: Cayenne
Issue Type: Task
Components: Core Library
Reporter: Nikita Timofeev
Assignee: Nikita Timofeev
Fix For: 5.0.M1
there's no reason for {{server}} to stay after ROP is gone and we don't have
any {{client}} counterparts.
Here are the most sensitive parts that will likely change as part of this task:
* {{cayenne-server}} module
* {{ServerRuntime}} and {{ServerRuntimeBuilder}}
* {{ServerModule}} and it's extender
* {{CayenneServerModuleProvider}} that backs module autoloading feature
* {{org.apache.cayenne.configuration.server}} package
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAY-2817) Pagination flow refactoring
[
https://issues.apache.org/jira/browse/CAY-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2817:
-
Summary: Pagination flow refactoring (was: Pagination flow refactoring
needed)
> Pagination flow refactoring
> ---
>
> Key: CAY-2817
> URL: https://issues.apache.org/jira/browse/CAY-2817
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Affects Versions: 5.0.M1
>Reporter: Ivan Nikitka
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0.M1
>
>
> The current process for pagination uses direct method for gathering data.
> Without any checks, validations and convertations.
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator performIteratedQuery(Query query)
> }{code}
> {code:java}
> public class IncrementalFaultList implements List, Serializable {
> ...
> protected void fillIn(final Query query, List elementsList) {
>elementsList.clear();
>try (ResultIterator it = dataContext.performIteratedQuery(query)) {
> while (it.hasNextRow()) {
> elementsList.add(it.nextRow());
> }
>}
>unfetchedObjects = elementsList.size();
> }{code}
> After applying [this|https://github.com/apache/cayenne/pull/594/] PR we need
> to redirect pagination flow to the
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator iterator(final Select query)
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2819) DataContext.performIteratedQuery() method should be unified with iterator() method
Nikita Timofeev created CAY-2819: Summary: DataContext.performIteratedQuery() method should be unified with iterator() method Key: CAY-2819 URL: https://issues.apache.org/jira/browse/CAY-2819 Project: Cayenne Issue Type: Task Components: Core Library Reporter: Nikita Timofeev Assignee: Nikita Timofeev Fix For: 5.0.M1 This one should be a part of CAY-2814, but it's blocked by CAY-2817. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2817) Pagination flow refactoring needed
[
https://issues.apache.org/jira/browse/CAY-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2817:
-
Fix Version/s: 5.0.M1
> Pagination flow refactoring needed
> --
>
> Key: CAY-2817
> URL: https://issues.apache.org/jira/browse/CAY-2817
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Affects Versions: 5.0.M1
>Reporter: Ivan Nikitka
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 5.0.M1
>
>
> The current process for pagination uses direct method for gathering data.
> Without any checks, validations and convertations.
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator performIteratedQuery(Query query)
> }{code}
> {code:java}
> public class IncrementalFaultList implements List, Serializable {
> ...
> protected void fillIn(final Query query, List elementsList) {
>elementsList.clear();
>try (ResultIterator it = dataContext.performIteratedQuery(query)) {
> while (it.hasNextRow()) {
> elementsList.add(it.nextRow());
> }
>}
>unfetchedObjects = elementsList.size();
> }{code}
> After applying [this|https://github.com/apache/cayenne/pull/594/] PR we need
> to redirect pagination flow to the
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator iterator(final Select query)
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAY-2817) Pagination flow refactoring needed
[
https://issues.apache.org/jira/browse/CAY-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784312#comment-17784312
]
Nikita Timofeev edited comment on CAY-2817 at 11/9/23 8:09 AM:
---
A little clarification on this issue. As mentioned it's raised while working on
CAY-2814. A {{dataContext.performIteratedQuery(query)}} method is used here
just because it bypasses many parts of the stack logic and doesn't go into a
cycle, not because we need an iterator here. And that leads to a problem that
we can't optimize and refactor this method until this issue is solved.
was (Author: ntimofeev):
A little clarification on this issue. As mentions it's raised while working on
CAY-2814. A {{dataContext.performIteratedQuery(query)}} method is used here
just because it bypasses many parts of the stack logic and doesn't go into a
cycle, not because we need an iterator here. And that leads to a problem that
we can't optimize and refactor this method until this issue is solved.
> Pagination flow refactoring needed
> --
>
> Key: CAY-2817
> URL: https://issues.apache.org/jira/browse/CAY-2817
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Affects Versions: 5.0.M1
>Reporter: Ivan Nikitka
>Assignee: Nikita Timofeev
>Priority: Major
>
> The current process for pagination uses direct method for gathering data.
> Without any checks, validations and convertations.
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator performIteratedQuery(Query query)
> }{code}
> {code:java}
> public class IncrementalFaultList implements List, Serializable {
> ...
> protected void fillIn(final Query query, List elementsList) {
>elementsList.clear();
>try (ResultIterator it = dataContext.performIteratedQuery(query)) {
> while (it.hasNextRow()) {
> elementsList.add(it.nextRow());
> }
>}
>unfetchedObjects = elementsList.size();
> }{code}
> After applying [this|https://github.com/apache/cayenne/pull/594/] PR we need
> to redirect pagination flow to the
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator iterator(final Select query)
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAY-2817) Pagination flow refactoring needed
[
https://issues.apache.org/jira/browse/CAY-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784312#comment-17784312
]
Nikita Timofeev commented on CAY-2817:
--
A little clarification on this issue. As mentions it's raised while working on
CAY-2814. A {{dataContext.performIteratedQuery(query)}} method is used here
just because it bypasses many parts of the stack logic and doesn't go into a
cycle, not because we need an iterator here. And that leads to a problem that
we can't optimize and refactor this method until this issue is solved.
> Pagination flow refactoring needed
> --
>
> Key: CAY-2817
> URL: https://issues.apache.org/jira/browse/CAY-2817
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Affects Versions: 5.0.M1
>Reporter: Ivan Nikitka
>Assignee: Nikita Timofeev
>Priority: Major
>
> The current process for pagination uses direct method for gathering data.
> Without any checks, validations and convertations.
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator performIteratedQuery(Query query)
> }{code}
> {code:java}
> public class IncrementalFaultList implements List, Serializable {
> ...
> protected void fillIn(final Query query, List elementsList) {
>elementsList.clear();
>try (ResultIterator it = dataContext.performIteratedQuery(query)) {
> while (it.hasNextRow()) {
> elementsList.add(it.nextRow());
> }
>}
>unfetchedObjects = elementsList.size();
> }{code}
> After applying [this|https://github.com/apache/cayenne/pull/594/] PR we need
> to redirect pagination flow to the
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator iterator(final Select query)
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAY-2817) Pagination flow refactoring needed
[
https://issues.apache.org/jira/browse/CAY-2817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev reassigned CAY-2817:
Assignee: Nikita Timofeev
> Pagination flow refactoring needed
> --
>
> Key: CAY-2817
> URL: https://issues.apache.org/jira/browse/CAY-2817
> Project: Cayenne
> Issue Type: Task
> Components: Core Library
>Affects Versions: 5.0.M1
>Reporter: Ivan Nikitka
>Assignee: Nikita Timofeev
>Priority: Major
>
> The current process for pagination uses direct method for gathering data.
> Without any checks, validations and convertations.
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator performIteratedQuery(Query query)
> }{code}
> {code:java}
> public class IncrementalFaultList implements List, Serializable {
> ...
> protected void fillIn(final Query query, List elementsList) {
>elementsList.clear();
>try (ResultIterator it = dataContext.performIteratedQuery(query)) {
> while (it.hasNextRow()) {
> elementsList.add(it.nextRow());
> }
>}
>unfetchedObjects = elementsList.size();
> }{code}
> After applying [this|https://github.com/apache/cayenne/pull/594/] PR we need
> to redirect pagination flow to the
> {code:java}
> public class DataContext extends BaseContext{
> ...
> public ResultIterator iterator(final Select query)
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2818) JDK 21 support
Nikita Timofeev created CAY-2818: Summary: JDK 21 support Key: CAY-2818 URL: https://issues.apache.org/jira/browse/CAY-2818 Project: Cayenne Issue Type: Task Reporter: Nikita Timofeev Assignee: Nikita Timofeev Fix For: 5.0.M1 JDK 21 is LTS so we need to support it. As always main blocker right now is Gradle that is [lacking support|https://docs.gradle.org/current/userguide/compatibility.html] for Java 21. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2814) Select query iterator() and batchIterator() methods return incorrect results
[
https://issues.apache.org/jira/browse/CAY-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2814:
-
Fix Version/s: (was: 4.1.2)
> Select query iterator() and batchIterator() methods return incorrect results
>
>
> Key: CAY-2814
> URL: https://issues.apache.org/jira/browse/CAY-2814
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.1.1, 4.2.RC1, 4.2
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0.M1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Iterated queries can handle only basic results like single entity,
> {{Object[]}} and {{DataRow}}
> everything else is missing in the processing.
> This affects ColumnQuery most as it can return many more variants.
> What variants are broken:
> * all selects: joint prefetches
> * column query: several entities or entity + some other fields
> * column query: embeddables
> * column query: map function (see CAY-2812)
> * maybe something else (?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2815) Incorrect translation of aliased expression
Nikita Timofeev created CAY-2815: Summary: Incorrect translation of aliased expression Key: CAY-2815 URL: https://issues.apache.org/jira/browse/CAY-2815 Project: Cayenne Issue Type: Bug Components: Database integration Reporter: Nikita Timofeev Assignee: Nikita Timofeev Fix For: 4.2.1, 5.0.M1 Fix for CAY-2810 brake SQL generation for some expressions with alias. For instance it breaks subquery that is used for LIMIT/OFFSET on Oracle DB. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2814) Select query iterator() and batchIterator() methods return incorrect results
[
https://issues.apache.org/jira/browse/CAY-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev updated CAY-2814:
-
Fix Version/s: 4.1.2
> Select query iterator() and batchIterator() methods return incorrect results
>
>
> Key: CAY-2814
> URL: https://issues.apache.org/jira/browse/CAY-2814
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.1.1, 4.2.RC1, 4.2
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.1.2, 4.2.1, 5.0.M1
>
>
> Iterated queries can handle only basic results like single entity,
> {{Object[]}} and {{DataRow}}
> everything else is missing in the processing.
> This affects ColumnQuery most as it can return many more variants.
> What variants are broken:
> * all selects: joint prefetches
> * column query: several entities or entity + some other fields
> * column query: embeddables
> * column query: map function (see CAY-2812)
> * maybe something else (?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CAY-2812) ColumnQuery mapper function is not applied in ResultBatchIterator
[
https://issues.apache.org/jira/browse/CAY-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Timofeev closed CAY-2812.
Resolution: Fixed
This is just a special case of CAY-2814
> ColumnQuery mapper function is not applied in ResultBatchIterator
> -
>
> Key: CAY-2812
> URL: https://issues.apache.org/jira/browse/CAY-2812
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.2
>Reporter: Nikita Timofeev
>Assignee: Nikita Timofeev
>Priority: Major
> Fix For: 4.2.1, 5.0.M1
>
>
> {{query.batchIterator()}} call always returns {{Object[]}} disregarding
> mapper set for the {{ColumnQuery}} causing {{ClassCastException}}
> Query example:
> {code:java}
> void select() {
> // actual type of the iterator will be Object[] instead of DTO
> ResultBatchIterator it = ObjectSelect.columnQuery(Entity.class,
> Entity.ATTRIBUTE1, Entity.ATTRIBUTE2)
> .map(this::toDto)
> .batchIterator(context, 100);
> }
> DTO toDto(Object[] data) {
> // ...
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
