cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Java type should be a property of DbEntity, not ObjEntity
Date Sun, 22 Jul 2012 16:59:13 GMT
Yeah, ObjAttribute will definitely preserve "type" as a "read-through" property. Otherwise
ROP won't work for instance (DbEntity data is not passed to the client). The only thing we'll
be preventing is mapping attributes with different Java types to the same column (e.g. item
#3 on my list - different subclasses in an inheritance tree attempting to map the same column
differently).

Andrus

On Jul 22, 2012, at 5:39 PM, Aristedes Maniatis wrote:

> Do we ever want it to be possible to create ObjEntities which don't map to a DbEntity
at all? Or even just attributes which don't (yet) have a column in the database? Perhaps they
are a future enhancement and we aren't ready to map them to the database, but we'd like to
start writing code around them.
> 
> How about ObjEntities which are just an interface?
> 
> I am not saying that these are very powerful use-cases, but that's all I can think of
just now. A nice improvement with your suggested change would be better validation in the
modeler. We'd be able to alert the user to an Integer mapped against a bigint. It would be
nice if the modeler still also showed the Java type in the ObjEntity view, even if this was
read only.
> 
> Ari
> 
> 
> On 22/07/12 8:20pm, Andrus Adamchik wrote:
>> 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.
>> 
>> Comments?
>> 
>> Andrus
>> 
>> [1] http://markmail.org/message/6bs2suislyfp3apk
>> 
> 
> -- 
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> 


Mime
View raw message