[
https://issues.apache.org/jira/browse/CAY-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689001#comment-17689001
]
Nikita Timofeev commented on CAY-2794:
--------------------------------------
[~mattraydub] Thanks for another one problem found and diagnosed. This part of
the code is really prone to errors.
I suspect that the culprit is this line:
https://github.com/apache/cayenne/blob/STABLE-4.2/cayenne-server/src/main/java/org/apache/cayenne/access/translator/select/DescriptorColumnExtractor.java#L123
Will try to just set the Java type for the result node related to the main
{{DbAttribute}} and leave additional ones out, so their type will be calculated
based on the DB type.
> Fix Incorrect JavaType for Vertical-Inheritance Attributes
> ----------------------------------------------------------
>
> Key: CAY-2794
> URL: https://issues.apache.org/jira/browse/CAY-2794
> 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, 5.0.M1
>
> Attachments: PastedGraphic-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When performing a query on a Vertically Inherited "concrete" DataObject, the
> {{SelectTranslator.getSql}} will build an incorrect
> {{ColumnDescriptor.javaClass}} when visiting the first attribute in
> {{{}DescriptorColumnExtractor.visitAttribute{}}}.
> Though the tests do not fail, I can see the bug exists by running
> {{VerticalInheritance.testInsertWithMultipleAttributeAndMultipleRelationship}}
> and putting a stop on {{{}SelectAction.performAction{}}}, right after this
> line: {{final String sql = translator.getSql();}}
> When inspecting the {{translator.columnDescriptors}} you will see that the
> first item in the array, for {{name=ID}} has
> {{{}javaClass=java.lang.String{}}}. I can see the pattern that the first
> ColumnDescriptor gets assigned the same javaClass as the first Attribute
> "visited". And for flattened Attribute paths, this first puts in the PK for
> the join. So in this case it won't "fail" because it can parse an INTEGER to
> a String. But in my actual application, I have a "birthDate" Attribute, type
> DATE {{{}java.util.Date{}}}, and my PKs are UUIDs, so it's failing to parse a
> UUID to a Date.
> Pretty certain the issue is with either
> {{DescriptorColumnExtractor.visitAttribute}} or
> {{{}DescriptorColumnExtractor.processTranslationResult{}}}, but I am still
> trying to understand it all.
> Hopefully you can follow what I am trying my best to describe.
> I will try to create a breaking test soon.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
