On Friday 08 February 2008 02:53:45 Oleg Broytmann wrote:

>    I have, as I have a few Decimal columns in the database of one of our
> company's commercial programs - we count money (dollars and cents). Until 
> now none of our customers has problems, though I doubt one has tried to
> sum up all those cents and fractions.

If I can find the time, I'd like to implement a double-entry journal/ledger 
accounting system in SQLObject.  Accounting reconciliation involves strict 
equalities; even slightly inaccurate recording of cents & fractions causes a 
lot of unnecessary extra work.  That's why I'm afraid of floating point.

I am too dumb to understand sqlite's data storage model, but quick 
consultation of Google yields up this conversation from just last weekend:

http://www.mail-archive.com/[EMAIL PROTECTED]/msg31198.html

"""
The case I'm dealing with that is not working like I want is the case of 
NUMERIC column type.  In SQLite, this column type gets an affinity of 
REAL. If I put in a value to the column as a string literal, say 
'123.23', it's stored as a REAL even though I specified it as a string 
in quotes. [...] I want to avoid the use of REAL types in this case because 
they can lead to rounding errors, which is the whole purpose of the NUMERIC 
type to begin with, in my understanding.
"""

Needless to say, this frightens me.  But rather than dropping the ideal of 
serverless installs of desktop apps, I am interested if there's a better way.

>    If you find a problem - please publish more details. In case of PySQLite
> there is a way to map data to/from strings for any data; currently
> SQLObject uses this feature to map strings to/from unicode, and map
> date/time strings; it would be possible to add a mapping for Decimals.

That sounds like a better way!  Strings should be a fine way to store 
fixed-point numbers of finite length.  Are there any considerations that 
might make this a bad idea?

cs



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Reply via email to