[
https://issues.apache.org/jira/browse/CAY-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrus Adamchik updated CAY-1752:
---------------------------------
Summary: DbAttribute should have "javaType" (was: Java type should be a
property of DbAttribute, not ObjAttribute)
> 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
>
>
> 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
--
This message was sent by Atlassian Jira
(v8.20.10#820010)