Difference in runtime decimal precision vs database precision - looking for a more elegant solution

I have the following scenario:   I'm doing a data import from system A into an NPE. This data includes many decimal values. For each record, I do a find or create in my application to find a matching object. If the object exists, overwrite all attributes with the values from system A If it doesn't exist, create it. Check if each object changed from their old values using the java action “objectHasChanged” If the object changed, send the changes to System B If the object didn't change, nothing happens. Now the problem is as follows: Decimals that are a whole number value (for instance, 6) are stored as 6 in the runtime. When I import the same data set again, “objectHasChanged” returns true. After some digging, this seems to happen because in the database, 6 is stored as 6.00000000. Since 6 is not literally the same as 6.00000000 even though they are functionally the same value, “objectHasChanged” returns true.   I'm now fixing this the ugly way, by applying a round($importdecimal, 8) so that each value in the runtime has the same decimal precision as in the database, which works fine, but it's not an elegant solution (and when new attributes are added, a developer might miss adding the round function). Does anyone know a more elegant solution that can also be maintained easily?    
1 answers

It is a bit technical but works fast en reliant. Create a java-action that concats all the values as a string with default decimal formatting and a java-action to calculate the CRC32 of both strings and compare them


import java.util.zip.CRC32;

	CRC32 crc = new CRC32();
	return crc.getValue();