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
