Re: SQL domain types in Cayenne

From: Stephen Winnall (stev..innall.ch)
Date: Mon Jan 19 2009 - 13:50:23 EST

  • Next message: wwwebi: "Mapping primary keys getter methods"

    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