Matt Watson created CAY-2794:
--------------------------------
Summary: Fix Incorrect JavaType for VerticalInheritance 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
Attachments: PastedGraphic-1.png
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)
