On Fri, Jul 11, 2008 at 12:32:18PM -0500, Christopher Singley wrote:
> On Friday 11 July 2008 11:39:28 Oleg Broytmann wrote:
> >It is now in the trunk, revision 3504. Thank you very much!
>
> I'm surprised that one as unskilled as myself can make a contribution, but
> happy to do it.
As a
On Friday 11 July 2008 11:39:28 Oleg Broytmann wrote:
>It is now in the trunk, revision 3504. Thank you very much!
I'm surprised that one as unskilled as myself can make a contribution, but
happy to do it.
If anyone else out there is trying to develop desktop financial applications
for SQLO
On Fri, Jul 11, 2008 at 08:23:05PM +0400, Oleg Broytmann wrote:
> (Now I have to copy your self.max to my implementation...)
It is now in the trunk, revision 3504. Thank you very much!
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmer
On Fri, Jul 11, 2008 at 10:34:07AM -0500, Christopher Singley wrote:
> >? Without str() the query is
> >
> > INSERT INTO test (d) VALUES (10.)
> >
> >but converting to floats is exactly what we want to prevent. With str()
> > the query is
> >
> > INSERT INTO test (d) VALUES ('10.')
On Friday 11 July 2008 09:36:22 Oleg Broytmann wrote:
>size is not used in the __init__().
I don't think size is very important for python Decimals (only for storage
engines). In working with decimals, the problem is always with precision,
rounding, strict equality, and so forth. Maybe I a
On Tue, Jul 01, 2008 at 03:17:14PM -0500, Christopher Singley wrote:
> class DecimalStringValidator(DecimalValidator):
> def __init__(self, *args, **kw):
> size = kw.pop('size', NoDefault)
size is not used in the __init__().
> precision = kw.pop('precision', NoDefault)
>
On Tue, Jul 01, 2008 at 03:17:14PM -0500, Christopher Singley wrote:
> How about something like this?
It looks good. I will test it and add to the trunk. Thank you!
> class DecimalStringValidator(DecimalValidator):
> def __init__(self, *args, **kw):
> size = kw.pop('size', NoDefaul
On Tuesday 01 July 2008 13:56:26 Oleg Broytmann wrote:
> Or, if 'quantize' is always equal to precision
Since I believe the intent is to enforce consistency between the Python model
and the persistent storage, that should be the case.
> class Example(sqlobject.SQLObject):
> value = sqlobj
On Tue, Jul 01, 2008 at 10:53:16PM +0400, Oleg Broytmann wrote:
>we can decide to add an
> additional parameter:
>
> class Example(sqlobject.SQLObject):
> value = sqlobject.DecimalCol(size=10, precision=precision,
> quantize=precision)
Or, if 'quantize' is always equal to preci
On Tue, Jul 01, 2008 at 12:52:31PM -0500, Christopher Singley wrote:
> class Example(sqlobject.SQLObject):
> value = sqlobject.DecimalCol(size=10, precision=precision,
> validator=PreciseDecimalValidator(precision=precision))
>
> But this is very inelegant. Is there a way to use intro
On Tuesday 01 July 2008 11:29:56 Oleg Broytmann wrote:
> On Thu, Feb 14, 2008 at 07:31:10PM +0300, Oleg Broytmann wrote:
> >DecimalCol will not be changed. I will add documentation explaining
> > the type affinity problem in SQLite.
> >There will be a new DecimalStringCol that stores Decima
On Thu, Feb 14, 2008 at 07:31:10PM +0300, Oleg Broytmann wrote:
>DecimalCol will not be changed. I will add documentation explaining the
> type affinity problem in SQLite.
>There will be a new DecimalStringCol that stores Decimals as text.
It is now in the trunk.
> If
> you want quanti
On Thu, Feb 14, 2008 at 10:40:08AM -0600, Christopher Singley wrote:
> I'll be happy to write a validator class for DecimalStringCol - that's easy,
> if I can pass it it size/precision.
When SQLObject instantiate a validator it can pass any initialization
values the validator wants. For a user
On Thursday 14 February 2008 10:31:10 Oleg Broytmann wrote:
> I will add documentation explaining the type affinity problem in SQLite.
I think that's a good idea. Let me know if I can help.
> There will be a new DecimalStringCol that stores Decimals as text. If
> you want quantization please
On Thu, Feb 14, 2008 at 05:59:23PM +0300, Oleg Broytmann wrote:
> we are making a workaround for the backend that doesn't have a decimal
> type. But the workaround has a price.
Well, my resolution on the issue is:
DecimalCol will not be changed. I will add documentation explaining the
type
On Thu, Feb 14, 2008 at 08:46:40AM -0600, Christopher Singley wrote:
> failing to quantize the data introduces
> inconsistencies.
Inconsistency between what? between different backends? Are they really
consistent by themselves?
> If I define a DecimalCol as size=10, precision=5, then when I f
On Thursday 14 February 2008 08:27:23 Oleg Broytmann wrote:
> Does SQLObject really needs to quantize user's decimals? Why not just
> pass them to the backend as is?
Well, the most important thing is to get DecimalCol() actually returning
decimals... I wouldn't want to lose focus of the easies
On Thu, Feb 14, 2008 at 07:52:10AM -0600, Christopher Singley wrote:
> Well, sqlite doesn't enforce anything, so these constraints
> just disappear.
Well, SQLite doesn't have a decimal type, to begin with...
> What about DecimalValidator in sqlobject/col.py (or a subclass)? That
> would seem
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
On Wed, Feb 13, 2008 at 11:59:22PM -0600, Christopher Singley wrote:
> How does the data get marshalled by SQLObject and/or sqlite?
See sqlobject/converters.py.
> The
> size/precision constraints aren't really enforced by sqlite, are they?
In current situation SQLite converts them to floa
On Wednesday 13 February 2008 17:45:25 Oleg Broytmann wrote:
> Yes, but think about (size=5, precision=5). SQLObject doesn't do
> a quantization, and SQLite will store "2112.123456789" - it is just
> a string - but what about the padding?..
How does the data get marshalled by SQLObject and/or s
On Wed, Feb 13, 2008 at 05:40:44PM -0600, Christopher Singley wrote:
> If you're always doing ORDER BY a single column with a fixed size/precision,
> then the case above (for size=13, precision=9) would actually be
> "0009.11000" and "2112.123456789"; I think all strings of that format
> shou
On Wednesday 13 February 2008 17:24:51 Oleg Broytmann wrote:
> Couldn't we get an incorrect result trying to compare right-padding
> "009.11" and "2112.123456789"? I.e., could we rely solely on the size, not
> counting the number of digits in fraction?
Is there a case where ORDER BY would opera
On Wed, Feb 13, 2008 at 05:11:13PM -0600, Christopher Singley wrote:
> I believe every DecimalCol explicitly declares a size, so the total width
> should be easy to calculate (i.e. size+1).
Couldn't we get an incorrect result trying to compare right-padding
"009.11" and "2112.123456789"? I.e.,
On Wednesday 13 February 2008 05:12:13 Oleg Broytmann wrote:
> On the other hand that could bring problems with SQL manipulations such
> as ORDER BY...
Not sure how important that functionality is, but couldn't problems be fixed
by prepending zero padding? Perhaps the str.rjust() function cou
On Tue, Feb 12, 2008 at 05:37:26PM -0600, Christopher Singley wrote:
> foo = Test(number=Decimal('23'))
> print type(foo.number)
Good catch.
Can you believe I am going to fix the entire problem with such small and
simple patch as
Index: col.py
==
Following up on this issue - here is a test.
===
from decimal import Decimal
from sqlobject import *
sqlhub.processConnection =
connectionForURI('sqlite:///path/to/decimaltest.db')
class Test(SQLObject):
number = DecimalCol(size=8, precision=4)
Test.createTable(ifNotExists=True)
foo = Test
On Fri, Feb 08, 2008 at 01:57:03PM -0600, Christopher Singley wrote:
> On Friday 08 February 2008 13:03:42 Oleg Broytmann wrote:
> >I don't remember Decimal can do conversion to string and back from
> > string preserving precision. Are you talking about converting to
> > floating-point string?
On Friday 08 February 2008 13:03:42 Oleg Broytmann wrote:
>I don't remember Decimal can do conversion to string and back from
> string preserving precision. Are you talking about converting to
> floating-point string? str(Decimal("1.1")) => '1.1'? I don't know if the
> conversion preserves all
On Fri, Feb 08, 2008 at 12:41:54PM -0600, Christopher Singley wrote:
> I guess the mapping Decimal <-> str ought to be pretty easy, since it's
> supported by Python's decimal module.
I don't remember Decimal can do conversion to string and back from
string preserving precision. Are you talking
On Friday 08 February 2008 11:25:57 Oleg Broytmann wrote:
>If you are going to use (or allow to use) the DB in external non-python
> tools you have to document the mapping, and even the documents could not
> help in case of standard tools that don't know anything about the mapping.
> The mappin
On Fri, Feb 08, 2008 at 11:06:40AM -0600, Christopher Singley wrote:
> On Friday 08 February 2008 02:53:45 Oleg Broytmann wrote:
> >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
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 t
On Thu, Feb 07, 2008 at 04:38:04PM -0600, Christopher Singley wrote:
> On Thursday 07 February 2008 15:58:37 Oleg Broytmann wrote:
> > Alas! There were two wiki sites but both are dead now. The lack of
> > resources on the admin site, and probably the lack of interest on the user
> > side.
>
> Str
On Thursday 07 February 2008 15:58:37 Oleg Broytmann wrote:
> Alas! There were two wiki sites but both are dead now. The lack of
> resources on the admin site, and probably the lack of interest on the user
> side.
Strange... isn't there supposed to be some renaissance of interest in ORM
tools
35 matches
Mail list logo
