Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
4.2, 5.0-M1
-
None
Description
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.