[
https://issues.apache.org/jira/browse/CAY-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564231#comment-13564231
]
Ilya Drabenia edited comment on CAY-1752 at 1/29/13 9:51 AM:
-------------------------------------------------------------
0002: Patch contains needed commentaries and deprecation for moved fields.
was (Author: idrabenia):
Patch contains needed commentaries and deprecation for moved fields.
> Java type should be a property of DbAttribute, not ObjAttribute
> ---------------------------------------------------------------
>
> 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
> Fix For: 3.2M1
>
> 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
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
