I was trying to get the sample running pointed to an MySQL database. I made the appropriate changes to load the right scripts, etc.
When I try to compile I found that the NUMBER(10,2) columns which had been mapped to be handled by the BigDecimal don't get initialized in the bean. If the column is nullable the object reference just doesn't get set to anything and left as null. However, if it is a not null column it tries to initialize the object to 0.00.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What would you expect as behavior? As far as I am concerned I see it that way:
1- If it is possible for the column's value to be null, the object's attribute does not need to be initialized and will be saved to the database as null.
2- If it is not permitted for the column to hold a null value, then it has to be initialized to some arbitrary value (0.0 is no better than any other value) for the database not to receive a null when saving the object.
It seems to me that these two basic rules where what the original contributors had in mind when writing their templates.
If this is not what you need, I may consider to implement another strategy to comply with your expectations.
Alain.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess I wasn't specific enough when I said it tried to initialize the object to 0.00. I mean that literally:
BigDecimal cost = 0.00;
It creates a compile error. I am assuming it should be:
BigDecimal cost = new BigDecimal(0.00);
Initialized to zero makes perfect sense to me, no argument there, it just needs to initialize it to an BigDecimal object that has been initialized to zero. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Before reporting it to the bug tracker, would you be kind enough to update your local source code from the (just corrected, I hope) CVS code and check if it is now functionning the right way?
Thanks for your help!
Alain.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was trying to get the sample running pointed to an MySQL database. I made the appropriate changes to load the right scripts, etc.
When I try to compile I found that the NUMBER(10,2) columns which had been mapped to be handled by the BigDecimal don't get initialized in the bean. If the column is nullable the object reference just doesn't get set to anything and left as null. However, if it is a not null column it tries to initialize the object to 0.00.
What would you expect as behavior? As far as I am concerned I see it that way:
1- If it is possible for the column's value to be null, the object's attribute does not need to be initialized and will be saved to the database as null.
2- If it is not permitted for the column to hold a null value, then it has to be initialized to some arbitrary value (0.0 is no better than any other value) for the database not to receive a null when saving the object.
It seems to me that these two basic rules where what the original contributors had in mind when writing their templates.
If this is not what you need, I may consider to implement another strategy to comply with your expectations.
Alain.
I guess I wasn't specific enough when I said it tried to initialize the object to 0.00. I mean that literally:
BigDecimal cost = 0.00;
It creates a compile error. I am assuming it should be:
BigDecimal cost = new BigDecimal(0.00);
Initialized to zero makes perfect sense to me, no argument there, it just needs to initialize it to an BigDecimal object that has been initialized to zero. :)
OK! That way it IS a bug.
Before reporting it to the bug tracker, would you be kind enough to update your local source code from the (just corrected, I hope) CVS code and check if it is now functionning the right way?
Thanks for your help!
Alain.