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 : Sun Jan 18 2009 - 10:16:46 EST