Hi Andrus
It may be worth mentioning that I'm coming at the problem from the
data side (rather than from code). I like to have my data well
organized before I start coding.
Steve
On 19 Jan 2009, at 19:06, Andrus Adamchik <andru..bjectstyle.org>
wrote:
> 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:51:43 EST