cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Drabenia (JIRA)" <>
Subject [jira] [Updated] (CAY-1752) Java type should be a property of DbAttribute, not ObjAttribute
Date Tue, 05 Feb 2013 18:40:11 GMT


Ilya Drabenia updated CAY-1752:

    Attachment: 0011-CAY-1752-Java-type-should-be-a-property-of-DbAttribu.patch

0011: Patch contains support of embedded type and starting of modeler refactoring.
> Java type should be a property of DbAttribute, not ObjAttribute
> ---------------------------------------------------------------
>                 Key: CAY-1752
>                 URL:
>             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, 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
> from here:
> 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]

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:

View raw message