On Thursday 14 February 2008 04:56:37 Oleg Broytmann wrote: > See sqlobject/converters.py.
So SQLObject passes the size/precision parameters to the DB backend only when the table is created, and after that leaves the DB to enforce these constraints? Well, sqlite doesn't enforce anything, so these constraints just disappear. What about DecimalValidator in sqlobject/col.py (or a subclass)? That would seem like a logical place to manually quantize decimals going to/from sqlobject. There's a 'state' argument that could maybe be used to pass in size/precision. > I have a solution - a second type of DecimalCol - named > DecimalStringCol, may be - to allow the user to choose which implementation > (s)he wants - the current one (ok for most DB except SQLite) or > strings-based. Giving the user choice is good. However, I think the current implementation of DecimalCol on sqlite is quite broken; maybe that shouldn't be left as the default. If a user expects an object to represent a decimal; but the objectl doesn't really have size and precision, doesn't really store numbers accurately, and isn't even consistent with the language's typing... to me, that is a dangerous structure. 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
