Thanks for the input. This is very much matches my understanding. One
thing we may want to check in Cayenne is why no base types were setup
during reverse engineering. This can be something about to the driver
failing to provide them though.
Andrus
On Jan 18, 2009, at 5:16 PM, Stephen Winnall wrote:
> Hi Andrus
>
> Thanks for your reply.
>
> On 18 Jan 2009, at 12:47, Andrus Adamchik wrote:
>
>> Cayenne won't pick up domain types on reverse engineering, but I
>> suspect that whatever type is picked by Cayenne, it will work (i.e.
>> Cayenne will be able to save and load a column value).
>
> In my case no type was recognised. The attributes were imported, but
> they didn't have a type.
>
>> Trying to see why it can be helpful to have a concept of a domain
>> type in Cayenne. If I understand correctly we are talking about
>> domain types concept as described here for PostgreSQL [1] (you
>> haven't mentioned which DB you are using).
>
> That's what I'm talking about, yes. I use PostgreSQL, but I'm trying
> to restrict myself to stuff which is in the SQL standard (I may be
> embarrassed if you ask me to elaborate on which version of the
> standard :-) 2006 doesn't seem to be there yet). I want to be as db-
> independent as possible.
>
>> So domain type is a constrained base type. Why would you bother to
>> reflect that in Java? Pre-commit validation? Some other reason?
>
> My schema contains SQL domain types because I found myself using the
> same varchar(N) definitions all over the place and I wanted to
> ensure that they were consistent. It seemed logical that the
> consistence should pervade to the Java code too. Really it's just
> the same as using constants and common class definitions as good
> practice when writing code (consistency and readability).
>
> The other case where I use SQL domain types is in providing
> constraints for integer types which will be mapped to enums in Java.
> The Java enum does all I need at the Java level, and the database
> constraints provide me with the consistency I want at the database
> level. And the two mechanisms complement each other nicely.
>
>> BTW, custom types in Java are supported via ExtendedType mechanism
>> [2], but this is mainly used to map custom Java classes, that may
>> not have special corresponding DB constructs (and in 99.9% of cases
>> they don't). You can reuse this mechanism to match your domain
>> types (although manually, as it won't be done by reverse
>> engineering), I am just not sure there's a value in it. I
>> appreciate if you can elaborate on that.
>
> My work-around has been to replace the SQL domain type uses with
> their base types in the schema (i.e. ignore domain types
> completely). I haven't looked at ExtendedType yet (though it's on my
> list in connection with SQLXML). I'm not particularly inclined to
> use ExtendedType for SQL domain types though: it's easier to macro-
> process the master schema source replacing the domain type usages
> with their base types!
>
> Hope this helps.
>
> Steve
>
>
This archive was generated by hypermail 2.0.0 : Mon Jan 19 2009 - 13:07:04 EST