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...
Yes, but this would be database specific, would work with Postgres but not with SAPDB, Oracle...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>
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:My proposal is to add precision and scale as column attributes and default to (19,2) which
<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
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
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
