[
https://issues.apache.org/jira/browse/CAY-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrus Adamchik updated CAY-1752:
---------------------------------
Description:
Let's make "javaType" a property of DbAttribute. By default it will be
auto-generated from JDBC type. And we can allow to optionally override it at
the ObjAttribute level (with an explicit conversion when creating objects from
DataRows).
h2. Problems it Solves
* Non-standard type mapping (the whole OTHER type implies we provide some Java
class for it). This provides runtime consistency and eliminates the internal
hacks such as when Cayenne would try to guess which ObjEntities might use this
DataRow, and populate DataRows with values corresponding to the ObjAttribute
type definitions. This clearly breaks layer separation and doesn't always work.
* Unexpected PK types. PK columns are often not mapped as ObjAttributes, so
their type is guessed by Cayenne, and if the type is something vague such as
NUMBER, you may get BigDecimals, and other inappropriate types, and you can no
longer reliably compare objects.
Prior discussions:
* http://markmail.org/message/6bs2suislyfp3apk
* http://markmail.org/message/icr7seqazgsdtewc
was:
from here: http://markmail.org/message/icr7seqazgsdtewc
I am thinking of redefining one of the mapping assumptions that was in Cayenne
since day one. In 3.2 I want to move attribute java type from ObjAttribute to
DbAttribute. The goal of this change is to improve consistency of the runtime
model. Current separation of Java and DB attribute types causes a whole class of
bugs and a whole class of hacks in the framework.
E.g.:
1. Unrecognized non-standard type mapping. This one is discussed at the moment
on the user list [1]. I suspect it has nothing to do with "custom" types, but
rather with non-JDBC default mapping of DB data to Java, regardless of the Java
type.
2. Hacks to recognize non-standard type mapping. When creating a DataRow,
Cayenne would try to guess which ObjEntities might use this DataRow, and
populate DataRows with values corresponding to the ObjAttribute type
definitions. This clearly breaks layer separation - lower layers have to know
too much about the higher layers of the stack. Besides it doesn't always work
anyways - see #3.
3. Extra mapping "flexibility" that doesn't really work. We had past Jiras when
the same column is mapped to different Java types in 2 different subclasses,
creating a mess in subclass-agnostic DataRows.
This is not a full list of problems, but gives you some idea. I am hoping the
suggested change would tie things up and leave no space for ambiguities.
[1] http://markmail.org/message/6bs2suislyfp3apk
> DbAttribute should have "javaType"
> ----------------------------------
>
> Key: CAY-1752
> URL: https://issues.apache.org/jira/browse/CAY-1752
> Project: Cayenne
> Issue Type: Improvement
> Components: Core Library
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
> Priority: Major
> Attachments:
> 0001-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 0002-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 0003-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 0004-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 0005-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 0006-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 0007-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 0008-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 0009-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 0010-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 0011-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 1-0001-0012-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 1-0013-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 1-0014-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 1-0015-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 1-0016-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch,
> 1-0017-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch
>
>
> Let's make "javaType" a property of DbAttribute. By default it will be
> auto-generated from JDBC type. And we can allow to optionally override it at
> the ObjAttribute level (with an explicit conversion when creating objects
> from DataRows).
> h2. Problems it Solves
> * Non-standard type mapping (the whole OTHER type implies we provide some
> Java class for it). This provides runtime consistency and eliminates the
> internal hacks such as when Cayenne would try to guess which ObjEntities
> might use this DataRow, and populate DataRows with values corresponding to
> the ObjAttribute type definitions. This clearly breaks layer separation and
> doesn't always work.
> * Unexpected PK types. PK columns are often not mapped as ObjAttributes, so
> their type is guessed by Cayenne, and if the type is something vague such as
> NUMBER, you may get BigDecimals, and other inappropriate types, and you can
> no longer reliably compare objects.
> Prior discussions:
> * http://markmail.org/message/6bs2suislyfp3apk
> * http://markmail.org/message/icr7seqazgsdtewc
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
