[
https://issues.apache.org/jira/browse/CAY-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrus Adamchik updated CAY-2740:
---------------------------------
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. This has been a
source of bugs since forever (though we got better at guessing proper types, so
it is not as pronounced in the modern versions).
h2. Effect on DB Import
Generally DbImport preserves everything in the Obj layer, and overrides
everything in Db layer. "DbAttribute.javaType" may be a custom value that needs
to be preserved. We should only override it if "DbAttribute.type" is changed on
import. And in case the previous value was non-default, we may need to present
an explicit confirmation dialog.
h2. Prior discussions:
* http://markmail.org/message/6bs2suislyfp3apk
* http://markmail.org/message/icr7seqazgsdtewc
was:
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.
h2. Effect on DB Import
Generally DbImport preserves everything in the Obj layer, and overrides
everything in Db layer. "DbAttribute.javaType" may be a custom value that needs
to be preserved. We should only override it if "DbAttribute.type" is changed on
import. And in case the previous value was non-default, we may need to present
an explicit confirmation dialog.
h2. Prior discussions:
* http://markmail.org/message/6bs2suislyfp3apk
* http://markmail.org/message/icr7seqazgsdtewc
> Mapping Proposal: DbAttribute should have its own Java type
> -----------------------------------------------------------
>
> Key: CAY-2740
> URL: https://issues.apache.org/jira/browse/CAY-2740
> Project: Cayenne
> Issue Type: Improvement
> Reporter: Andrus Adamchik
> Priority: Major
>
> 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. This has been
> a source of bugs since forever (though we got better at guessing proper
> types, so it is not as pronounced in the modern versions).
> h2. Effect on DB Import
> Generally DbImport preserves everything in the Obj layer, and overrides
> everything in Db layer. "DbAttribute.javaType" may be a custom value that
> needs to be preserved. We should only override it if "DbAttribute.type" is
> changed on import. And in case the previous value was non-default, we may
> need to present an explicit confirmation dialog.
> h2. Prior discussions:
> * http://markmail.org/message/6bs2suislyfp3apk
> * http://markmail.org/message/icr7seqazgsdtewc
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
