CCK decimal: non-significant zeros conflict

precisely, I'm casting the actual value the wrong way, decimal places are lost, moreover types don't match, difference is being considered true for every case

once fixed (probably this weekend) I would suggest to drop every row (in comment_driven_log table) referencing those comments (by cid) affected by this bug, which will result in amnesia regarding these changes instead of wrong diff summaries

but display properly (with .00) in node.

I quickly set up a Float CCK field, and I only get decimal places if they are distinct from zero
how/where do I configure to display decimal even when they are zero?
in the formatter?
I set up display formatter "9,999.99" and still node_form doesn't show decimal places

also, I'm not getting the "string vs double" assertion

please, describe how to create such a CCK field: type, widget, default value, etc

I can make it go away without knowing what is causing it (since I know what that assertion is guarding)

but what that assertion is guarding is not supposed to receive "string vs double"
it might receive "double vs string" (a case I haven't seen so far), but not the other way around

I would prefer to know what kind of widget you have there which treats the $value as an actual float number instead of string (which is what CCK does)

oh damn, I was testing with Float instead of Decimal
then almost certain it would be a bug, since I never tried Decimal on my tests
I thought it was all the same with numbers: bad assumption

this comment contains technical details, for me and other developers that might fall into a tricky issue like this

as I said @#3
it might receive "double vs string", which would be an uncommon case I haven't seen so far and it is not being considered (yet), therefore another use case (3rd party code) might come up with such assertion, which I intend to study when the case comes up

also said @#3
it is not supposed to receive "string vs double"
but number_decimal_validate is converting $value from string to double:

      $value = str_replace($element['#decimal'], '.', $value);
      $value = round($value, $element['#scale']);
      form_set_value($element[$field_key], $value, $form_state);

then, another problem arises (beyond the type of the compared operands) when comparing "3.00" vs "3"
the $default comes from node_load/DB where (for instead having a precision of 10 and scale of 2) the type of the column would be DECIMAL(10,2), and loaded as string having all its non-significant zeros, while the $value (in $form_state['value']) was changed to double (because of the round on validation) and won't contain those decimal zeros on the extreme right #461536-2: $form_state['values'] not reflecting an accurate decimal value (i.e. non-significant zeros are dropped)

this particularities doesn't justify supporting "string vs double" nor "double vs string" comparison, since every other use case treats double numbers as string in $form_state['value'] (as every submitted value use to be) except this particular interest of number_decimal_validate for having accurate decimal values (which resulted in DB layer strings preserving their non-significant)

not sure if the proposed fix will be accepted by CCK #461536-6: $form_state['values'] not reflecting an accurate decimal value (i.e. non-significant zeros are dropped)
I'll support this as a special case anyway (and follow up in case the proposal be accepted)

committed to HEAD

I won't change the issue title, because it would be less clear,
but technically speaking it would be:
protect against CCK decimal numbers handling $form_state['values'] as double instead of string #461536-7: $form_state['values'] not reflecting an accurate decimal value (i.e. non-significant zeros are dropped)

now it shouldn't be present in HEAD

I also would recommend testing (with unstable5) and providing feedback at the CCK proposed patch cited above (#461536-7)

its been more than two weeks since I marked this issue as fixed
please, don't extend its live unless intending to leave further feedback

feel free to reopen it for any kind of comments,
but otherwise, just let it get closed for inactivity

I still suggest to push for getting this fixed in CCK instead (see above #7 & #10)
now I found that this problem got shifted and being reflected as a bug when previewing

#760694: CCK decimal: non-significant zeros when previewing