SQL domain types in Cayenne

[Stephen Winnall <st...@winnall.ch>]

Does Cayenne support SQL domain types? I have a schema with a few  
CREATE DOMAIN statements in it, and Cayenne seems to have ignored them  
when I reverse-engineered the schema.

My naive expectation was that "CREATE DOMAIN dom AS x" Cayenne would  
create a Java class Dom which was a subclass of whatever it generated  
for x.

Steve

Re: SQL domain types in Cayenne

[Stephen Winnall <st...@winnall.ch>]

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 <an...@objectstyle.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
>>
>>
>

Re: SQL domain types in Cayenne

[Andrus Adamchik <an...@objectstyle.org>]

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
>
>

Re: SQL domain types in Cayenne

[Stephen Winnall <st...@winnall.ch>]

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

Re: SQL domain types in Cayenne

[Andrus Adamchik <an...@objectstyle.org>]

Hi Steve,

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).

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). So domain type is a constrained  
base type. Why would you bother to reflect that in Java? Pre-commit  
validation? Some other reason?

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.

Andrus

[1] http://www.network-theory.co.uk/docs/postgresql/vol1/CREATEDOMAIN.html
[2] http://cayenne.apache.org/doc/extended-types.html


On Jan 18, 2009, at 3:15 AM, Stephen Winnall wrote:

> Does Cayenne support SQL domain types? I have a schema with a few  
> CREATE DOMAIN statements in it, and Cayenne seems to have ignored  
> them when I reverse-engineered the schema.
>
> My naive expectation was that "CREATE DOMAIN dom AS x" Cayenne would  
> create a Java class Dom which was a subclass of whatever it  
> generated for x.
>
> Steve
>
>