[jira] [Commented] (CAY-2794) Fix Incorrect JavaType for Vertical-Inheritance Attributes

["Matt Watson (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAY-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688771#comment-17688771 ] 

Matt Watson commented on CAY-2794:
----------------------------------

[~ntimofeev] 

[Here is the pull request|https://github.com/apache/cayenne/pull/565] with the breaking change/test...

All I had to do was add a Date attribute to `IvImpl`, and one of the existing tests failed. But, I did go ahead and set that attribute to a Date value in that test, just so someone doesn't decide to remove that attribute in the future.

Still looking for a solution.

> 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
>            Priority: Major
>         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)