Re: [Hibernate] Postgres NUMERIC and other problems

[Andrea A. <aa...@li...>]

Gavin King wrote:

>>Basically, there are two problems:
>>- the same foreign key is generated two times (artplFK1, artplFK2)
>>    
>>
>
>That won't happen if you declare one end of the bidirectional association
>with readonly="true" which is the preferred style.
>  
>

Ah, I see. But if I allow editing on both sides, what can go wrong? I 
mean, either the programmer
should not be allowed to mark both sides as editable or the fk should 
not be generated two times...
I will have a look at the code and see if we can avoid this...

>Yeah, I know.....I didn't quite know what to do about NUMERIC types....we
>really should allow precision and scale attributes as well as length, but
>that is starting to complicate the DTD too much. What we will probably have
>to do eventually is allow them on the <column> element rather than the
><property> elements, etc. However, you can already do this:
>
><property name="cost" type="big_decimal">
>    <column sql-type="NUMERIC(19,2)"/>
></property>
>
>  
>
Yes, but this would be database specific, would work with Postgres but 
not with SAPDB, Oracle...
One of the greatest features of the mapping file is that it is database 
agnonistc, using the sql-type
attribute you lose this feature...

>Which is actually less typing than:
>
><property name="cost" type="big_decimal">
>    <column precision="19" scale="2">
></property>
>
>So I couldn't be bothered with that just yet.
>
>If you are voluteering to fix this stuff, your help is very welcome ;)
>
>Gavin
>
>  
>
My proposal is to add precision and scale as column attributes and 
default to (19,2) which
seems to me the most reasonable default, since that would treat all 
databases in an uniform
way. The numeric default type is allowed to grow to the implementation 
limits, that is, a very
big size I guess, which means a very big space overhead on the disk, or 
to a non uniform treatment
of the data contained in the column (like a BLOB type), which may be 
very slow. If one needs
the NUMERIC without precision and scale specification he is asking for a 
PostgreSQL 
specific feature, so it would be reasonable to use the sql-type directly.
If you agree I can have a look at the implementation...
Best regards
Andrea Aime