[jira] [Created] (CAY-2863) DbEntity qualifiers are no longer applied to JOIN conditions
Jurgen Doll created CAY-2863:
Summary: DbEntity qualifiers are no longer applied to JOIN
conditions
Key: CAY-2863
URL: https://issues.apache.org/jira/browse/CAY-2863
Project: Cayenne
Issue Type: Bug
Components: Core Library
Affects Versions: 4.2.1, 4.2, 5.0-M2
Reporter: Jurgen Doll
This is a regression from 3.1.3
DbEntity qualifiers used to be applied to JOIN conditions but have now moved to
the WHERE clause. This results in queries returning no results when there are
OR conditions in the WHERE part that could satisfy the query.
Here's a possible test case for DefaultSelectTranslatorIT.java
{code:java}
@Test
public void testDbEntityQualifier_JoinQuery() throws Exception {
final DbEntity entity =
context.getEntityResolver().getDbEntity("ARTIST");
entity.setQualifier(ExpressionFactory.exp("ARTIST_NAME = 'Should be on
JOIN condition and not WHERE'"));
ObjectSelect q = ObjectSelect.query(Painting.class)
.where
(
Painting.TO_ARTIST.dot(Artist.DATE_OF_BIRTH).eq(new
java.sql.Date(1,0,1))
.orExp( Painting.TO_GALLERY.dot( Gallery.GALLERY_NAME ).like(
"G%" ) )
);
// If the DbEntity qualifier is set on the WHERE condition then the OR
expression will fail to find matches
SelectTranslator transl = new DefaultSelectTranslator(q,
dataNode.getAdapter(), dataNode.getEntityResolver());
try {
String generatedSql = transl.getSql();
int whereNdx = generatedSql.indexOf(" WHERE ");
int joinNdx = generatedSql.indexOf(" JOIN ARTIST ");
assertTrue(generatedSql.substring(joinNdx,
whereNdx).indexOf("ARTIST_NAME") > 0); // Should be in JOIN condition
assertTrue(generatedSql.indexOf("ARTIST_NAME", whereNdx) < 0); //
Should not be part of WHERE
}
finally {
entity.setQualifier(null);
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAY-2854) Improve delete prevention detection of flattened attribute row
[ https://issues.apache.org/jira/browse/CAY-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845704#comment-17845704 ] Jurgen Doll commented on CAY-2854: -- Submitted [PR 615|https://github.com/apache/cayenne/pull/615] > Improve delete prevention detection of flattened attribute row > -- > > Key: CAY-2854 > URL: https://issues.apache.org/jira/browse/CAY-2854 > Project: Cayenne > Issue Type: Sub-task > Components: Core Library >Affects Versions: 5.0-M1 >Reporter: Jurgen Doll >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Weather a flattened attribute row should/should not be deleted is currently > detected each time during each delete query construction (see [PR > 614|https://github.com/apache/cayenne/pull/614]). > This can be optimized by doing the detection during ClassDescriptor > construction and setting a relevant flag instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2854) Improve delete prevention detection of flattened attribute row
Jurgen Doll created CAY-2854: Summary: Improve delete prevention detection of flattened attribute row Key: CAY-2854 URL: https://issues.apache.org/jira/browse/CAY-2854 Project: Cayenne Issue Type: Sub-task Components: Core Library Affects Versions: 5.0-M1 Reporter: Jurgen Doll Weather a flattened attribute row should/should not be deleted is currently detected each time during each delete query construction (see [PR 614|https://github.com/apache/cayenne/pull/614]). This can be optimized by doing the detection during ClassDescriptor construction and setting a relevant flag instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAY-2853) Incorrect deletion of entities from flattened attributes
[ https://issues.apache.org/jira/browse/CAY-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844385#comment-17844385 ] Jurgen Doll commented on CAY-2853: -- Submitted [PR|https://github.com/apache/cayenne/pull/614/files] > Incorrect deletion of entities from flattened attributes > > > Key: CAY-2853 > URL: https://issues.apache.org/jira/browse/CAY-2853 > Project: Cayenne > Issue Type: Bug > Components: Core Library >Affects Versions: 4.2, 5.0-M2 >Reporter: Jurgen Doll >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > When deleting an ObjEntity with flattened attributes Cayenne deletes the > related DB attribute's row as well. > > So if we have for example an ObjEntity "FlatPainting" with flattened > attribute "galleryName". If we then delete a "FlatPainting" then the > associated gallery will also be deleted, leaving all other paintings at that > gallery without a valid Gallery link. > > Furthermore if we add to our "FlatPainting" a "gallery" relationship > attribute with delete rule Deny, the gallery is still deleted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2853) Incorrect deletion of entities from flattened attributes
Jurgen Doll created CAY-2853: Summary: Incorrect deletion of entities from flattened attributes Key: CAY-2853 URL: https://issues.apache.org/jira/browse/CAY-2853 Project: Cayenne Issue Type: Bug Components: Core Library Affects Versions: 4.2, 5.0-M2 Reporter: Jurgen Doll When deleting an ObjEntity with flattened attributes Cayenne deletes the related DB attribute's row as well. So if we have for example an ObjEntity "FlatPainting" with flattened attribute "galleryName". If we then delete a "FlatPainting" then the associated gallery will also be deleted, leaving all other paintings at that gallery without a valid Gallery link. Furthermore if we add to our "FlatPainting" a "gallery" relationship attribute with delete rule Deny, the gallery is still deleted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAY-2850) Query using Clob comparison with empty String fails
[
https://issues.apache.org/jira/browse/CAY-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836906#comment-17836906
]
Jurgen Doll commented on CAY-2850:
--
Created a [PR|https://github.com/apache/cayenne/pull/611]
> Query using Clob comparison with empty String fails
> ---
>
> Key: CAY-2850
> URL: https://issues.apache.org/jira/browse/CAY-2850
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
>Affects Versions: 4.2, 5.0-M2
>Reporter: Jurgen Doll
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When executing a query where the predicate contains something like CLOB_COL
> != '' then a CayenneRuntimeException is thrown with the cause being specified
> as "SQLSyntaxErrorException: precision or scale out of range".
> This happens because the predicate gets translated into the following SQL:
> "cast( t0.CLOB_COL as varchar({*}0{*}) )" where the varchar length is zero !
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAY-2850) Query using Clob comparison with empty String fails
Jurgen Doll created CAY-2850:
Summary: Query using Clob comparison with empty String fails
Key: CAY-2850
URL: https://issues.apache.org/jira/browse/CAY-2850
Project: Cayenne
Issue Type: Bug
Components: Core Library
Affects Versions: 4.2, 5.0-M2
Reporter: Jurgen Doll
When executing a query where the predicate contains something like CLOB_COL !=
'' then a CayenneRuntimeException is thrown with the cause being specified as
"SQLSyntaxErrorException: precision or scale out of range".
This happens because the predicate gets translated into the following SQL:
"cast( t0.CLOB_COL as varchar({*}0{*}) )" where the varchar length is zero !
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAY-2847) Improve duplicate select column detection when using order by
[ https://issues.apache.org/jira/browse/CAY-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822152#comment-17822152 ] Jurgen Doll commented on CAY-2847: -- Created a [PR|https://github.com/apache/cayenne/pull/610] > Improve duplicate select column detection when using order by > - > > Key: CAY-2847 > URL: https://issues.apache.org/jira/browse/CAY-2847 > Project: Cayenne > Issue Type: Sub-task > Components: Core Library >Reporter: Jurgen Doll >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The current implementation has three problems: > # It fails when a column has an alias > # It builds the whole SQL column string before comparing > # It doesn't seem very robust in preventing false results > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2847) Improve duplicate select column detection when using order by
Jurgen Doll created CAY-2847: Summary: Improve duplicate select column detection when using order by Key: CAY-2847 URL: https://issues.apache.org/jira/browse/CAY-2847 Project: Cayenne Issue Type: Sub-task Components: Core Library Reporter: Jurgen Doll The current implementation has three problems: # It fails when a column has an alias # It builds the whole SQL column string before comparing # It doesn't seem very robust in preventing false results -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2842) Prevent duplicate select columns when using distinct with order by
[ https://issues.apache.org/jira/browse/CAY-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jurgen Doll updated CAY-2842: - Fix Version/s: (was: 5.0-M2) > Prevent duplicate select columns when using distinct with order by > -- > > Key: CAY-2842 > URL: https://issues.apache.org/jira/browse/CAY-2842 > Project: Cayenne > Issue Type: Improvement > Components: Core Library >Affects Versions: 4.2 >Reporter: Jurgen Doll >Priority: Minor > Labels: pull-request-available > Time Spent: 6h 50m > Remaining Estimate: 0h > > When a "select distinct" query has an "order by" clause then the "order by" > fields must also be listed in the select clause. However no check is > currently done to see if the column is already specified which can result in > duplicate columns being fetched. > This is listed as a TODO item in OrderingStage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2842) Prevent duplicate select columns when using distinct with order by
[ https://issues.apache.org/jira/browse/CAY-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jurgen Doll updated CAY-2842: - Fix Version/s: 5.0-M2 > Prevent duplicate select columns when using distinct with order by > -- > > Key: CAY-2842 > URL: https://issues.apache.org/jira/browse/CAY-2842 > Project: Cayenne > Issue Type: Improvement > Components: Core Library >Affects Versions: 4.2 >Reporter: Jurgen Doll >Priority: Minor > Labels: pull-request-available > Fix For: 5.0-M2 > > Time Spent: 6h 40m > Remaining Estimate: 0h > > When a "select distinct" query has an "order by" clause then the "order by" > fields must also be listed in the select clause. However no check is > currently done to see if the column is already specified which can result in > duplicate columns being fetched. > This is listed as a TODO item in OrderingStage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17815333#comment-17815333 ] Jurgen Doll commented on CAY-2843: -- Created a [PR|https://github.com/apache/cayenne/pull/606] containing a potential solution that passes the tests. > 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 >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > 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] [Created] (CAY-2843) Use an IN clause for single field disjoint by ID prefetches
Jurgen Doll created CAY-2843: Summary: 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 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-2842) Prevent duplicate select columns when using distinct with order by
[ https://issues.apache.org/jira/browse/CAY-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815273#comment-17815273 ] Jurgen Doll commented on CAY-2842: -- Created a [PR|https://github.com/apache/cayenne/pull/605] containing a failing test and a potential solution that passes the tests. > Prevent duplicate select columns when using distinct with order by > -- > > Key: CAY-2842 > URL: https://issues.apache.org/jira/browse/CAY-2842 > Project: Cayenne > Issue Type: Improvement > Components: Core Library >Affects Versions: 4.2 >Reporter: Jurgen Doll >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > When a "select distinct" query has an "order by" clause then the "order by" > fields must also be listed in the select clause. However no check is > currently done to see if the column is already specified which can result in > duplicate columns being fetched. > This is listed as a TODO item in OrderingStage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2842) Prevent duplicate select columns when using distinct with order by
Jurgen Doll created CAY-2842: Summary: Prevent duplicate select columns when using distinct with order by Key: CAY-2842 URL: https://issues.apache.org/jira/browse/CAY-2842 Project: Cayenne Issue Type: Improvement Components: Core Library Affects Versions: 4.2 Reporter: Jurgen Doll When a "select distinct" query has an "order by" clause then the "order by" fields must also be listed in the select clause. However no check is currently done to see if the column is already specified which can result in duplicate columns being fetched. This is listed as a TODO item in OrderingStage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAY-2841) Multi column ColumnSelect with SHARED_CACHE fails after 1st select
Jurgen Doll created CAY-2841:
Summary: 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
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-2254) Move PrePersist & PreUpdate lifecycle events to occur before validation
[ https://issues.apache.org/jira/browse/CAY-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jurgen Doll updated CAY-2254: - Affects Version/s: 4.2 > Move PrePersist & PreUpdate lifecycle events to occur before validation > --- > > Key: CAY-2254 > URL: https://issues.apache.org/jira/browse/CAY-2254 > Project: Cayenne > Issue Type: Improvement > Components: Core Library, Documentation >Affects Versions: 4.0.M3, 4.0.M4, 4.0.M5, 3.1, 3.1.1, 3.1.2, 4.2 >Reporter: Jurgen Doll >Priority: Minor > > With regards to the PrePersist & PreUpdate lifecycle events it appears that > developers are expecting these events to take place before validation occurs, > as the original docs for 3.1 also indicate. > Developers are trying to use these as a place to set default values before > the actual commit occurs, but validation prevents this from happening. It was > also noted that to make changes to the data after validation is not good > practice. > Options: > 1. Move the lifecycle events to occur before validation (and update the docs > for 4) > 2. or Update the docs to clarify the function of PrePersist & PreUpdate, i.e. > what it is for, what it is not for, and provide suggestions as to where / how > to accomplish the not for things that developers are currently trying to do. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAY-2254) Move PrePersist & PreUpdate lifecycle events to occur before validation
[ https://issues.apache.org/jira/browse/CAY-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jurgen Doll updated CAY-2254: - Affects Version/s: 3.1.2 > Move PrePersist & PreUpdate lifecycle events to occur before validation > --- > > Key: CAY-2254 > URL: https://issues.apache.org/jira/browse/CAY-2254 > Project: Cayenne > Issue Type: Improvement > Components: Core Library, Documentation >Affects Versions: 3.1, 3.1.1, 4.0.M3, 4.0.M4, 3.1.2, 4.0.M5 >Reporter: Jurgen Doll >Priority: Minor > > With regards to the PrePersist & PreUpdate lifecycle events it appears that > developers are expecting these events to take place before validation occurs, > as the original docs for 3.1 also indicate. > Developers are trying to use these as a place to set default values before > the actual commit occurs, but validation prevents this from happening. It was > also noted that to make changes to the data after validation is not good > practice. > Options: > 1. Move the lifecycle events to occur before validation (and update the docs > for 4) > 2. or Update the docs to clarify the function of PrePersist & PreUpdate, i.e. > what it is for, what it is not for, and provide suggestions as to where / how > to accomplish the not for things that developers are currently trying to do. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAY-2254) Move PrePersist & PreUpdate lifecycle events to occur before validation
Jurgen Doll created CAY-2254: Summary: Move PrePersist & PreUpdate lifecycle events to occur before validation Key: CAY-2254 URL: https://issues.apache.org/jira/browse/CAY-2254 Project: Cayenne Issue Type: Improvement Components: Core Library, Documentation Affects Versions: 4.0.M4, 4.0.M3, 3.1.1, 3.1 Reporter: Jurgen Doll Priority: Minor With regards to the PrePersist & PreUpdate lifecycle events it appears that developers are expecting these events to take place before validation occurs, as the original docs for 3.1 also indicate. Developers are trying to use these as a place to set default values before the actual commit occurs, but validation prevents this from happening. It was also noted that to make changes to the data after validation is not good practice. Options: 1. Move the lifecycle events to occur before validation (and update the docs for 4) 2. or Update the docs to clarify the function of PrePersist & PreUpdate, i.e. what it is for, what it is not for, and provide suggestions as to where / how to accomplish the not for things that developers are currently trying to do. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAY-2085) Duplicate JOIN in Cayenne SQL
Jurgen Doll created CAY-2085:
Summary: Duplicate JOIN in Cayenne SQL
Key: CAY-2085
URL: https://issues.apache.org/jira/browse/CAY-2085
Project: Cayenne
Issue Type: Bug
Components: Core Library
Affects Versions: 3.1.1, 3.1
Reporter: Jurgen Doll
I have 3 DbEntities related to one another:
RPT_TEMPLATE_GROUPS -> L_RPT_TEMPLATE_GROUPS -> RPT_TEMPLATE_OBJECTS
And I have 2 ObjEntities based on them:
ReportTemplate (RPT_TEMPLATE_GROUPS) with relationship getLines()
ReportTemplateLine (RPT_TEMPLATE_OBJECTS)
However an unusual feature is that ReportTemplateLine has an attribute "order"
that has a Db Path to a field in L_RPT_TEMPLATE_GROUPS
The result of this arrangement when invoking ReportTemplate.getLines() is the
following SQL, excluding select fields:
SELECT * FROM RPT_TEMPLATE_OBJECTS t0 LEFT
JOIN L_RPT_TEMPLATE_GROUPS t1 ON (t0.RPT_TEMP_ID = t1.RPT_TEMP_ID){color:red}
JOIN L_RPT_TEMPLATE_GROUPS t2 ON (t0.RPT_TEMP_ID = t2.RPT_TEMP_ID){color}
WHERE t2.RPT_TEMP_GROUP_ID = ?
Note the duplicate join which is unnecessary and results in the DB returning
incorrect rows.
Another issue related to this occurred while trying to create a work around by
using SQLTemplate with a corrected form of the above SQL. The query executes
correctly but when accessing each object Cayenne does a DB request (even though
all the required data is present):
SELECT * FROM PRT_TEMPLATE_OBJECTS t0
LEFT JOIN L_RPT_TEMPLATE_GROUPS t1 ON (t0.RPT_TEMP_ID = t1.RPT_TEMP_ID)
WHERE t0.RPT_T_OBJ_ID = ?
In summary then there is firstly a superfluous JOIN resulting in incorrect
data, and secondly a superfluous DB query when the data/field is already
present.
Here is my data map:
http://cayenne.apache.org/schema/3.0/modelMap;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://cayenne.apache.org/schema/3.0/modelMap
http://cayenne.apache.org/schema/3.0/modelMap.xsd;
project-version="6">
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAY-1909) Constants.TRANSACTION_ISOLATION property
Jurgen Doll created CAY-1909: Summary: Constants.TRANSACTION_ISOLATION property Key: CAY-1909 URL: https://issues.apache.org/jira/browse/CAY-1909 Project: Cayenne Issue Type: Improvement Reporter: Jurgen Doll There is no easy way of changing the default transaction isolation level of connections when using a XMLPoolingDataSourceFactory. Since there are already other constants related to db connections in org.apache.cayenne.configuration.Constants maybe a TRANSACTION_ISOLATION property can be accommodated which could then be put into the Constants.PROPERTIES_MAP and used when creating connections. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAY-1910) Enable Password Encoder tab in Modeler for DBCPDataSourceFactory
Jurgen Doll created CAY-1910: Summary: Enable Password Encoder tab in Modeler for DBCPDataSourceFactory Key: CAY-1910 URL: https://issues.apache.org/jira/browse/CAY-1910 Project: Cayenne Issue Type: Improvement Components: Core Library, Modeler Reporter: Jurgen Doll Currently the Password Encoder tab is only enabled for the XMLPoolingDataSourceFactory. It would be nice if the DBCPDataSourceFactory could also use this functionality. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAY-1834) Exception: ToManyList cannot be cast to DataObject
[ https://issues.apache.org/jira/browse/CAY-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13729532#comment-13729532 ] Jurgen Doll commented on CAY-1834: -- Thanks. Exception: ToManyList cannot be cast to DataObject -- Key: CAY-1834 URL: https://issues.apache.org/jira/browse/CAY-1834 Project: Cayenne Issue Type: Bug Components: Core Library Affects Versions: 3.1B2 Reporter: Jurgen Doll Fix For: 3.2M2 Attachments: 0001-xx.patch, VisionsMap.map.xml I have an entity called Activity with a M-N relationship to ActivityResults (No middle or linking table). The relationship getResults() returns a MAPname,ActivityResults, but the exception also occurs when using a ListActivityResults. I have found that selecting To Many on the dbEntity backing the child class (ActivityResults) produces the exception. While switching To Many off removes the exception and commits succesfully. If an existing ActivityResult is modified and the Activity is then committed the updates related to the ActivityResults are successful, but rolled back as an exception is thrown when post-processing Activity: java.lang.ClassCastException: org.apache.cayenne.access.ToManyList cannot be cast to org.apache.cayenne.DataObject at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.toDataObject(DataObjectBaseProperty.java:97) at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.readPropertyDirectly(DataObjectBaseProperty.java:70) at org.apache.cayenne.reflect.generic.DataObjectToManyProperty.isFault(DataObjectToManyProperty.java:106) at org.apache.cayenne.access.DataDomainSyncBucket.postprocess(DataDomainSyncBucket.java:257) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAY-1834) Exception: ToManyList cannot be cast to DataObject
[ https://issues.apache.org/jira/browse/CAY-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jurgen Doll updated CAY-1834: - Priority: Major (was: Blocker) Exception: ToManyList cannot be cast to DataObject -- Key: CAY-1834 URL: https://issues.apache.org/jira/browse/CAY-1834 Project: Cayenne Issue Type: Bug Components: Core Library Affects Versions: 3.1B2 Reporter: Jurgen Doll Attachments: VisionsMap.map.xml I have an entity called Activity with a M-N relationship to ActivityResults (No middle or linking table). The relationship getResults() returns a MAPname,ActivityResults, but the exception also occurs when using a ListActivityResults. I have found that selecting To Many on the dbEntity backing the child class (ActivityResults) produces the exception. While switching To Many off removes the exception and commits succesfully. If an existing ActivityResult is modified and the Activity is then committed the updates related to the ActivityResults are successful, but rolled back as an exception is thrown when post-processing Activity: java.lang.ClassCastException: org.apache.cayenne.access.ToManyList cannot be cast to org.apache.cayenne.DataObject at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.toDataObject(DataObjectBaseProperty.java:97) at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.readPropertyDirectly(DataObjectBaseProperty.java:70) at org.apache.cayenne.reflect.generic.DataObjectToManyProperty.isFault(DataObjectToManyProperty.java:106) at org.apache.cayenne.access.DataDomainSyncBucket.postprocess(DataDomainSyncBucket.java:257) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAY-1834) Exception: ToManyList cannot be cast to DataObject
Jurgen Doll created CAY-1834: Summary: Exception: ToManyList cannot be cast to DataObject Key: CAY-1834 URL: https://issues.apache.org/jira/browse/CAY-1834 Project: Cayenne Issue Type: Bug Components: Core Library Affects Versions: 3.1B2 Reporter: Jurgen Doll Priority: Blocker I have an entity called Activity with a M-N relationship to ActivityResults (No middle or linking table). The relationship getResults() returns a MAPname,ActivityResults, but the exception also occurs when using a ListActivityResults. I have found that selecting To Many on the dbEntity backing the child class (ActivityResults) produces the exception. While switching To Many off removes the exception and commits succesfully. If an existing ActivityResult is modified and the Activity is then committed the exception produced is: java.lang.ClassCastException: org.apache.cayenne.access.ToManyList cannot be cast to org.apache.cayenne.DataObject at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.toDataObject(DataObjectBaseProperty.java:97) at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.readPropertyDirectly(DataObjectBaseProperty.java:70) at org.apache.cayenne.reflect.generic.DataObjectToManyProperty.isFault(DataObjectToManyProperty.java:106) at org.apache.cayenne.access.DataDomainSyncBucket.postprocess(DataDomainSyncBucket.java:257) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAY-1834) Exception: ToManyList cannot be cast to DataObject
[ https://issues.apache.org/jira/browse/CAY-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jurgen Doll updated CAY-1834: - Description: I have an entity called Activity with a M-N relationship to ActivityResults (No middle or linking table). The relationship getResults() returns a MAPname,ActivityResults, but the exception also occurs when using a ListActivityResults. I have found that selecting To Many on the dbEntity backing the child class (ActivityResults) produces the exception. While switching To Many off removes the exception and commits succesfully. If an existing ActivityResult is modified and the Activity is then committed the updates related to the ActivityResults are successful, but rolled back as an exception is thrown when post-processing Activity: java.lang.ClassCastException: org.apache.cayenne.access.ToManyList cannot be cast to org.apache.cayenne.DataObject at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.toDataObject(DataObjectBaseProperty.java:97) at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.readPropertyDirectly(DataObjectBaseProperty.java:70) at org.apache.cayenne.reflect.generic.DataObjectToManyProperty.isFault(DataObjectToManyProperty.java:106) at org.apache.cayenne.access.DataDomainSyncBucket.postprocess(DataDomainSyncBucket.java:257) was: I have an entity called Activity with a M-N relationship to ActivityResults (No middle or linking table). The relationship getResults() returns a MAPname,ActivityResults, but the exception also occurs when using a ListActivityResults. I have found that selecting To Many on the dbEntity backing the child class (ActivityResults) produces the exception. While switching To Many off removes the exception and commits succesfully. If an existing ActivityResult is modified and the Activity is then committed the exception produced is: java.lang.ClassCastException: org.apache.cayenne.access.ToManyList cannot be cast to org.apache.cayenne.DataObject at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.toDataObject(DataObjectBaseProperty.java:97) at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.readPropertyDirectly(DataObjectBaseProperty.java:70) at org.apache.cayenne.reflect.generic.DataObjectToManyProperty.isFault(DataObjectToManyProperty.java:106) at org.apache.cayenne.access.DataDomainSyncBucket.postprocess(DataDomainSyncBucket.java:257) Exception: ToManyList cannot be cast to DataObject -- Key: CAY-1834 URL: https://issues.apache.org/jira/browse/CAY-1834 Project: Cayenne Issue Type: Bug Components: Core Library Affects Versions: 3.1B2 Reporter: Jurgen Doll Priority: Blocker I have an entity called Activity with a M-N relationship to ActivityResults (No middle or linking table). The relationship getResults() returns a MAPname,ActivityResults, but the exception also occurs when using a ListActivityResults. I have found that selecting To Many on the dbEntity backing the child class (ActivityResults) produces the exception. While switching To Many off removes the exception and commits succesfully. If an existing ActivityResult is modified and the Activity is then committed the updates related to the ActivityResults are successful, but rolled back as an exception is thrown when post-processing Activity: java.lang.ClassCastException: org.apache.cayenne.access.ToManyList cannot be cast to org.apache.cayenne.DataObject at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.toDataObject(DataObjectBaseProperty.java:97) at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.readPropertyDirectly(DataObjectBaseProperty.java:70) at org.apache.cayenne.reflect.generic.DataObjectToManyProperty.isFault(DataObjectToManyProperty.java:106) at org.apache.cayenne.access.DataDomainSyncBucket.postprocess(DataDomainSyncBucket.java:257) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAY-1834) Exception: ToManyList cannot be cast to DataObject
[ https://issues.apache.org/jira/browse/CAY-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jurgen Doll updated CAY-1834: - Attachment: VisionsMap.map.xml Exception: ToManyList cannot be cast to DataObject -- Key: CAY-1834 URL: https://issues.apache.org/jira/browse/CAY-1834 Project: Cayenne Issue Type: Bug Components: Core Library Affects Versions: 3.1B2 Reporter: Jurgen Doll Priority: Blocker Attachments: VisionsMap.map.xml I have an entity called Activity with a M-N relationship to ActivityResults (No middle or linking table). The relationship getResults() returns a MAPname,ActivityResults, but the exception also occurs when using a ListActivityResults. I have found that selecting To Many on the dbEntity backing the child class (ActivityResults) produces the exception. While switching To Many off removes the exception and commits succesfully. If an existing ActivityResult is modified and the Activity is then committed the updates related to the ActivityResults are successful, but rolled back as an exception is thrown when post-processing Activity: java.lang.ClassCastException: org.apache.cayenne.access.ToManyList cannot be cast to org.apache.cayenne.DataObject at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.toDataObject(DataObjectBaseProperty.java:97) at org.apache.cayenne.reflect.generic.DataObjectBaseProperty.readPropertyDirectly(DataObjectBaseProperty.java:70) at org.apache.cayenne.reflect.generic.DataObjectToManyProperty.isFault(DataObjectToManyProperty.java:106) at org.apache.cayenne.access.DataDomainSyncBucket.postprocess(DataDomainSyncBucket.java:257) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
