cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Winnall <>
Subject Re: SQL domain types in Cayenne
Date Sun, 18 Jan 2009 15:16:05 GMT
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.


View raw message