sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] DecimalCol

[Oleg B. <ph...@ma...>]

On Mon, Dec 06, 2004 at 03:53:47PM -0600, Ian Bicking wrote:
> >DecimalCol it's probably a bug, but that's another story.
>
> No, it's required for DecimalCol -- databases require size and
> precision.  At least, the ones I know of do...?  There's no default for

   MySQL, I suppose? :)

> size, hence the assertion.

   Postgres 7.2:

"Both the precision and the scale of the numeric type can be configured.
To declare a column of type numeric use the syntax

 NUMERIC(precision, scale)

   The precision must be positive, the scale zero or positive.
Alternatively,

 NUMERIC(precision)

   selects a scale of 0. Specifying

 NUMERIC

   without any precision or scale creates a column in which numeric
values of any precision and scale can be stored, up to the
implementation limit on precision. A column of this kind will not coerce
input values to any particular scale, whereas numeric columns with a
declared scale will coerce input values to that scale."

Oleg.
--
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] StringCol with variable sized TEXT columns

[Ian B. <ia...@co...>]

Oleg Broytmann wrote:
> On Mon, Dec 06, 2004 at 07:35:44PM -0200, Carlos Ribeiro wrote:
> 
>>    observacao  = StringCol(notNone = False, default = '')
>>
>>I've got this:
>>
>>cribeiro@fiona:~/work/workflow $ python dbsidercom.py
>>Traceback (most recent call last):
>>  File "dbsidercom.py", line 556, in ?
>>    _wf = WorkflowBasico(DEFAULT_DB_FILENAME)
>>  File "/home/cribeiro/work/workflow/dbworkflow.py", line 40, in __init__
>>    self.defineCustomDB(db)
>>  File "dbsidercom.py", line 60, in defineCustomDB
>>    class dbNotaFiscal(SQLObject):
>>  File "/usr/lib/python2.3/site-packages/sqlobject/main.py", line 177,
>>in __new__
>>    newClass.addColumn(column)
>>  File "/usr/lib/python2.3/site-packages/sqlobject/main.py", line 387,
>>in addColumn
>>    column = columnDef.withClass(cls)
>>  File "/usr/lib/python2.3/site-packages/sqlobject/col.py", line 286,
>>in withClass
>>    return self.baseClass(soClass=soClass, name=self._name, **self.kw)
>>  File "/usr/lib/python2.3/site-packages/sqlobject/col.py", line 600,
>>in __init__
>>    assert self.size is not NoDefault, \
>>AssertionError: You must give a size argument
> 
> 
>    What is your version of SQLObject? I can find only one such assert in
> col.py, in line 606 - in DecimalCol, not StringCol. Well, even in
> DecimalCol it's probably a bug, but that's another story.

No, it's required for DecimalCol -- databases require size and 
precision.  At least, the ones I know of do...?  There's no default for 
size, hence the assertion.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] StringCol with variable sized TEXT columns

[Ian B. <ia...@co...>]

Carlos Ribeiro wrote:
> As per the documentation:
> 
> "StringCol represents CHAR, VARCHAR, and TEXT. The length keyword
> argument indicates the CHAR or VARCHAR length -- if not given, then
> TEXT is assumed. If you use varchar=False then CHAR will be used,
> otherwise VARCHAR is the default."
 >
> But when I tried:
> 
>     <-- rest of the declaration ommited -->
>     observacao  = StringCol(notNone = False, default = '')
> 
> I've got this:
> 
> cribeiro@fiona:~/work/workflow $ python dbsidercom.py
> Traceback (most recent call last):
>   File "dbsidercom.py", line 556, in ?
>     _wf = WorkflowBasico(DEFAULT_DB_FILENAME)
>   File "/home/cribeiro/work/workflow/dbworkflow.py", line 40, in __init__
>     self.defineCustomDB(db)
>   File "dbsidercom.py", line 60, in defineCustomDB
>     class dbNotaFiscal(SQLObject):
>   File "/usr/lib/python2.3/site-packages/sqlobject/main.py", line 177,
> in __new__
>     newClass.addColumn(column)
>   File "/usr/lib/python2.3/site-packages/sqlobject/main.py", line 387,
> in addColumn
>     column = columnDef.withClass(cls)
>   File "/usr/lib/python2.3/site-packages/sqlobject/col.py", line 286,
> in withClass
>     return self.baseClass(soClass=soClass, name=self._name, **self.kw)
>   File "/usr/lib/python2.3/site-packages/sqlobject/col.py", line 600,
> in __init__
>     assert self.size is not NoDefault, \
> AssertionError: You must give a size argument

The lines don't match up with the current checkout, but the only place I 
see that line is for DecimalCol, not StringCol.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] StringCol with variable sized TEXT columns

[Oleg B. <ph...@ma...>]

On Mon, Dec 06, 2004 at 07:35:44PM -0200, Carlos Ribeiro wrote:
>     observacao  = StringCol(notNone = False, default = '')
> 
> I've got this:
> 
> cribeiro@fiona:~/work/workflow $ python dbsidercom.py
> Traceback (most recent call last):
>   File "dbsidercom.py", line 556, in ?
>     _wf = WorkflowBasico(DEFAULT_DB_FILENAME)
>   File "/home/cribeiro/work/workflow/dbworkflow.py", line 40, in __init__
>     self.defineCustomDB(db)
>   File "dbsidercom.py", line 60, in defineCustomDB
>     class dbNotaFiscal(SQLObject):
>   File "/usr/lib/python2.3/site-packages/sqlobject/main.py", line 177,
> in __new__
>     newClass.addColumn(column)
>   File "/usr/lib/python2.3/site-packages/sqlobject/main.py", line 387,
> in addColumn
>     column = columnDef.withClass(cls)
>   File "/usr/lib/python2.3/site-packages/sqlobject/col.py", line 286,
> in withClass
>     return self.baseClass(soClass=soClass, name=self._name, **self.kw)
>   File "/usr/lib/python2.3/site-packages/sqlobject/col.py", line 600,
> in __init__
>     assert self.size is not NoDefault, \
> AssertionError: You must give a size argument

   What is your version of SQLObject? I can find only one such assert in
col.py, in line 606 - in DecimalCol, not StringCol. Well, even in
DecimalCol it's probably a bug, but that's another story.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] StringCol with variable sized TEXT columns

[Carlos R. <car...@gm...>]

As per the documentation:

"StringCol represents CHAR, VARCHAR, and TEXT. The length keyword
argument indicates the CHAR or VARCHAR length -- if not given, then
TEXT is assumed. If you use varchar=False then CHAR will be used,
otherwise VARCHAR is the default."

But when I tried:

    <-- rest of the declaration ommited -->
    observacao  = StringCol(notNone = False, default = '')

I've got this:

cribeiro@fiona:~/work/workflow $ python dbsidercom.py
Traceback (most recent call last):
  File "dbsidercom.py", line 556, in ?
    _wf = WorkflowBasico(DEFAULT_DB_FILENAME)
  File "/home/cribeiro/work/workflow/dbworkflow.py", line 40, in __init__
    self.defineCustomDB(db)
  File "dbsidercom.py", line 60, in defineCustomDB
    class dbNotaFiscal(SQLObject):
  File "/usr/lib/python2.3/site-packages/sqlobject/main.py", line 177,
in __new__
    newClass.addColumn(column)
  File "/usr/lib/python2.3/site-packages/sqlobject/main.py", line 387,
in addColumn
    column = columnDef.withClass(cls)
  File "/usr/lib/python2.3/site-packages/sqlobject/col.py", line 286,
in withClass
    return self.baseClass(soClass=soClass, name=self._name, **self.kw)
  File "/usr/lib/python2.3/site-packages/sqlobject/col.py", line 600,
in __init__
    assert self.size is not NoDefault, \
AssertionError: You must give a size argument


What's wrong here, the documentation or the StringCol constructor?

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Scott S. <sc...@st...>]

On Dec 6, 2004, at 11:10 AM, Ian Bicking wrote:
> Maybe it would be helpful if the registry had a method to return the 
> names of all the classes that are still pending?  That would be:
>
> def pendingClasses(self):
>     return self.callbacks.keys()
>
> After you've loaded a class, you could check if there were any pending 
> classes, and try to load them up.

This is essentially all I am trying to do, solve the chicken/egg 
problem.  This would be a fine solution to the problem.

Thanks
Scott

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Ian B. <ia...@co...>]

Scott Sanders wrote:
>> I'm not entirely clear what you are thinking.  Right now the registry 
>> tracks classes, but it never returns classes.  Instead class 
>> references are pushed into the places they are needed, using callbacks 
>> which are triggered on class creation.  So I'm not sure where this 
>> would fit.
> 
> 
> The registry always returns a class when asked (for classes in joins, 
> etc),  or am I just smoking something???  I understand it never 
> generates a class.

The registry is meant to deal with circular references, which is why it 
doesn't return classes at all.  Since if A depends on B, and B depends 
on A, the calls will look like:

class A:
     my_b = registry.getClass('B') # registry goes off and creates B...

class B:
     my_a = registry.getClass('A') # but A doesn't exist yet, and
     # it won't until B is finished being created


Instead it works like:

import classregistry
registry = classregistry.registry('default')

class A:
     pass
registry.addClassCallback('B', lambda cls: A.my_b = cls)
registry.addClass(A)
# So far the registry hasn't done anything at all

class B:
     pass
registry.addClassCallback('A', lambda cls: B.my_a = cls)
# The registry immediately calls that lambda passing in A
registry.addClass(B)
# The registry now calls the previous lambda, passing in B


Maybe it would be helpful if the registry had a method to return the 
names of all the classes that are still pending?  That would be:

def pendingClasses(self):
     return self.callbacks.keys()

After you've loaded a class, you could check if there were any pending 
classes, and try to load them up.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Scott S. <sc...@st...>]

On Dec 5, 2004, at 1:20 PM, Ian Bicking wrote:
>>>
>>> I have successfully been using SQLObject svn trunk for a few days 
>>> now, without modifications.  I have implemented automatic class 
>>> generation by reading information from the database about classes 
>>> and their columns and joins.  I did this by extending MetaSQLObject 
>>> with my own behavior, and a factory method called 
>>> getClass(classname), which checks the registry, and then constructs 
>>> a new class if the registry does not contain the proper class.
>
> This sounds very similar to ezSqlObject, except it uses __getattr__ to 
> create the classes (e.g., db.User, instead of getClass('user')).

yes, it would be similar.

>
>>> The problem I am running into now, is when you have joined classes, 
>>> the joined classes have to be explicitly loaded.  In your 
>>> users/roles example, my code would have to look something like this:
>>> userClass = getClass('user')
>>> roleClass = getClass('role') #if this is not called here, user.roles 
>>> will not be defined, because the role class is not in the registry
>>> user = userClass.get(1)
>>> print list(user.roles[0])
>
> So you are creating the joins dynamically as well?  How does that 
> work?  How lazy do you need the class creation to be?

Yes, I am creating the joins dynamically, which creates the problem 
that I don't know which classes are going to join to other non-existent 
classes.  I don't care about lazy, my only problem is that the python 
code that is written will not know which child/grandchild classes will 
need to exist.

>
> I notice there's no .tables() method on connections, just 
> .tableExists() -- it's a pretty no-brainer that such a method should 
> exist, returning a list of strings.  Would that be enough?  Then you 
> could create all the classes at startup.

If the answer from the SQLObject team is to create them up front, I am 
willing to do that.  I would just rather not.

>
>>> It would great if the registry was allowed to have a factory method 
>>> set to attempt automatic class creation if the class does not exist. 
>>>  If I coded this up as a patch, would it be accepted?
>
> I'm not entirely clear what you are thinking.  Right now the registry 
> tracks classes, but it never returns classes.  Instead class 
> references are pushed into the places they are needed, using callbacks 
> which are triggered on class creation.  So I'm not sure where this 
> would fit.

The registry always returns a class when asked (for classes in joins, 
etc),  or am I just smoking something???  I understand it never 
generates a class.

Scott

Re: [SQLObject] Decimal type support

[Carlos R. <car...@gm...>]

On Mon, 06 Dec 2004 12:04:21 -0600, Ian Bicking <ia...@co...> wrote:
> Carlos Ribeiro wrote:
> > I remember posting a comment about the state of the DB API on c.l.py a
> > couple of months ago (soon after the famous AMK blog post on the std
> > library), and being quickly flamed by some well know DB-SIG members.
> > So that's *really* hard.
> 
> It won't be hard for the decimal type -- the decimal type is an issue of
> correctness.  It might be hard to make it actually *happen* given the
> development process for any particular driver, but everyone knows
> returning a Python decimal for a DB decimal column is the Right Thing.
> All you have to ask is, "how do I do it?" and if there's not a way, "how
> can we change the driver to allow me to do it?"

Well, you're probably right. But that's realy not for a short
timeframe though. I think I'll be using floats for now -- they did
just fine up to this point, if used with proper care at the right
locations, and I should not be in a hurry to replace it. I may be able
to come up with a Decimals patch in the next few weeks (surely it's
not going to be my top priority).

I'll follow yours (Ian and Oleg) feedback, and subscribe to the
DB-SIG, to check how do they feel about it. I'm lucky enough (I guess)
to have three platforms installed & working here: PostgreSQL, MySQL
and sqlite, so I think I can test with these. Let's see what I can
bake here...

Thanks for the info and for the encouragement :-)

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] Decimal type support

[Ian B. <ia...@co...>]

Carlos Ribeiro wrote:
> On Mon, 6 Dec 2004 20:09:53 +0300, Oleg Broytmann <ph...@ma...> wrote:
> 
>>On Mon, Dec 06, 2004 at 03:00:02PM -0200, Carlos Ribeiro wrote:
>>
>>>I really don't know what to do.
>>
>>   Wait until DB API 3 implements Decimal in drivers. To speed things up
>>start discussing DB API 3 in the db-sig, and send patches for your
>>driver.
>>   Yes, that's hard...
> 
> 
> I remember posting a comment about the state of the DB API on c.l.py a
> couple of months ago (soon after the famous AMK blog post on the std
> library), and being quickly flamed by some well know DB-SIG members.
> So that's *really* hard.

It won't be hard for the decimal type -- the decimal type is an issue of 
correctness.  It might be hard to make it actually *happen* given the 
development process for any particular driver, but everyone knows 
returning a Python decimal for a DB decimal column is the Right Thing. 
All you have to ask is, "how do I do it?" and if there's not a way, "how 
can we change the driver to allow me to do it?"

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] Decimal type support

[Oleg B. <ph...@ma...>]

On Mon, Dec 06, 2004 at 03:23:26PM -0200, Carlos Ribeiro wrote:
> I remember posting a comment about the state of the DB API on c.l.py a
> couple of months ago (soon after the famous AMK blog post on the std
> library), and being quickly flamed by some well know DB-SIG members.
> So that's *really* hard.

   <Wry grin>

> BTW, one of the reasons I've chosen to use SQLObject is that it
> allowed me to abstract out the database implementation details much
> more effectively than the DB API itself does.

   But now you want to extend something. You can do it in your program,
or try to extend SQLObject, or do it in DB API level...

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Decimal type support

[Carlos R. <car...@gm...>]

On Mon, 6 Dec 2004 20:09:53 +0300, Oleg Broytmann <ph...@ma...> wrote:
> On Mon, Dec 06, 2004 at 03:00:02PM -0200, Carlos Ribeiro wrote:
> > I really don't know what to do.
> 
>    Wait until DB API 3 implements Decimal in drivers. To speed things up
> start discussing DB API 3 in the db-sig, and send patches for your
> driver.
>    Yes, that's hard...

I remember posting a comment about the state of the DB API on c.l.py a
couple of months ago (soon after the famous AMK blog post on the std
library), and being quickly flamed by some well know DB-SIG members.
So that's *really* hard.

BTW, one of the reasons I've chosen to use SQLObject is that it
allowed me to abstract out the database implementation details much
more effectively than the DB API itself does. At the time I'd thought
that I would rather wash my hands in boiling water than start another
discussion on the DB-SIG. Oh dear, own naive :-)

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] Decimal type support

[Ian B. <ia...@co...>]

Carlos Ribeiro wrote:
> On Mon, 06 Dec 2004 10:15:34 -0600, Ian Bicking <ia...@co...> wrote:
> 
>>Carlos Ribeiro wrote:
>>
>>>I just downloaded & installed the decimal module (the same from Python
>>>2.4) for Python 2.3. I know that SQLObject has a DecimalCol type. I've
>>>tried to check the code that actually fetches decimal values from the
>>>DB, but I got a little bit lost on SQLObject internals at this point.
>>>I trie to grep for Decimal and found only a few references, so I
>>>assume it's not full implemented yet.
>>
>>One way would be to handle the conversion through the driver.  This
>>should be doable with psycopg.  Some way you have to get the value from
>>the database, probably as a string, then convert it to decimal.
>>Obviously it's not very helpful if you get it from the database as a
>>float, then convert it to a decimal.
>>
>>Right now there's no good hooks for coercing something before it is
>>returned.  E.g., in Postgres I think that'd be something like "SELECT
>>(CAST dec_column AS TEXT) AS dec_column", which would keep psycopg from
>>converting to a float.
> 
> 
> Humm. Decimals should always be passed around either as native
> decimals or as strings; the Decimal constructor takes a string as a
> parameter, and that's the only way to preserve precision. There are a
> few ways out of this problem:
> 
> 1) Rely on the DB driver working with native decimals (perhaps with
> some patches, as you suggested, to trick the DB to use a string as an
> intermediate value). That's a definitive solution but I'm not sure
> even how to start it.

It depends what backends you are targetting.  If Postgres/psycopg, you 
should be able to modify its type coercion fairly easily.  For other 
database drivers, I'm not sure.  There's no standard DB API way to 
manage type conversion, but I imagine there are interested people in 
each case, and workaround solutions.  This seems like the easiest 
course, and the end result (getting drivers to return decimal types 
natively) will benefit everyone.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] Decimal type support

[Oleg B. <ph...@ma...>]

On Mon, Dec 06, 2004 at 03:00:02PM -0200, Carlos Ribeiro wrote:
> I really don't know what to do.

   Wait until DB API 3 implements Decimal in drivers. To speed things up
start discussing DB API 3 in the db-sig, and send patches for your
driver.
   Yes, that's hard...

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Decimal type support

[Carlos R. <car...@gm...>]

On Mon, 06 Dec 2004 10:15:34 -0600, Ian Bicking <ia...@co...> wrote:
> Carlos Ribeiro wrote:
> > I just downloaded & installed the decimal module (the same from Python
> > 2.4) for Python 2.3. I know that SQLObject has a DecimalCol type. I've
> > tried to check the code that actually fetches decimal values from the
> > DB, but I got a little bit lost on SQLObject internals at this point.
> > I trie to grep for Decimal and found only a few references, so I
> > assume it's not full implemented yet.
> 
> One way would be to handle the conversion through the driver.  This
> should be doable with psycopg.  Some way you have to get the value from
> the database, probably as a string, then convert it to decimal.
> Obviously it's not very helpful if you get it from the database as a
> float, then convert it to a decimal.
> 
> Right now there's no good hooks for coercing something before it is
> returned.  E.g., in Postgres I think that'd be something like "SELECT
> (CAST dec_column AS TEXT) AS dec_column", which would keep psycopg from
> converting to a float.

Humm. Decimals should always be passed around either as native
decimals or as strings; the Decimal constructor takes a string as a
parameter, and that's the only way to preserve precision. There are a
few ways out of this problem:

1) Rely on the DB driver working with native decimals (perhaps with
some patches, as you suggested, to trick the DB to use a string as an
intermediate value). That's a definitive solution but I'm not sure
even how to start it.

2) Forget decimals on the DB -- store everything as strings, and
convert to native Decimals on reading & writing. This works, but in
this case I can't rely on the DB itself for any arithmetic
manipulation. That will cause problems with aggregate SQL clauses
(SUM, MAX, etc.).

I really don't know what to do. Implementing Decimal support in
SQLObject would be nice, but I fear that it will take a lot of time
and require a lot of knowledge about individual database drivers. What
a problem...


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] Decimal type support

[Carlos R. <car...@gm...>]

On Mon, 6 Dec 2004 19:09:46 +0300, Oleg Broytmann <ph...@ma...> wrote:
> On Mon, Dec 06, 2004 at 01:59:27PM -0200, Carlos Ribeiro wrote:
> > somewhere with the fromPython/toPython validators, but I'm
> > still trying to figure out where to put my code into
> 
>    This how I do it for Unicode columns:
> http://sourceforge.net/mailarchive/message.php?msg_id=10177526
>    Decimal should not be any harder.
> 
> Oleg.

Thanks for the pointer. I've read that message when first posted, and
that was exactly what I was trying to do for Decimal. After some code
reading, I think I began to understand how to make it work. I'll try
it a little bit here, and if I make it work (with all tests, etc) I'll
post a patch. But don't hold your breath, please :-)

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] Decimal type support

[Ian B. <ia...@co...>]

Carlos Ribeiro wrote:
> I just downloaded & installed the decimal module (the same from Python
> 2.4) for Python 2.3. I know that SQLObject has a DecimalCol type. I've
> tried to check the code that actually fetches decimal values from the
> DB, but I got a little bit lost on SQLObject internals at this point.
> I trie to grep for Decimal and found only a few references, so I
> assume it's not full implemented yet.

One way would be to handle the conversion through the driver.  This 
should be doable with psycopg.  Some way you have to get the value from 
the database, probably as a string, then convert it to decimal. 
Obviously it's not very helpful if you get it from the database as a 
float, then convert it to a decimal.

Right now there's no good hooks for coercing something before it is 
returned.  E.g., in Postgres I think that'd be something like "SELECT 
(CAST dec_column AS TEXT) AS dec_column", which would keep psycopg from 
converting to a float.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] Decimal type support

[Oleg B. <ph...@ma...>]

On Mon, Dec 06, 2004 at 01:59:27PM -0200, Carlos Ribeiro wrote:
> somewhere with the fromPython/toPython validators, but I'm
> still trying to figure out where to put my code into

   This how I do it for Unicode columns:
http://sourceforge.net/mailarchive/message.php?msg_id=10177526
   Decimal should not be any harder.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Decimal type support

[Carlos R. <car...@gm...>]

Hello all,


I just downloaded & installed the decimal module (the same from Python
2.4) for Python 2.3. I know that SQLObject has a DecimalCol type. I've
tried to check the code that actually fetches decimal values from the
DB, but I got a little bit lost on SQLObject internals at this point.
I trie to grep for Decimal and found only a few references, so I
assume it's not full implemented yet.

What I want to do is to make sure that the get & set methods for the
decimal columns returns the appropriate Decimal type, if it's
installed on the system, instead of a float. I assume that this is to
be done somewhere with the fromPython/toPython validators, but I'm
still trying to figure out where to put my code into. Any help (and
experiences with Decimal) will be great.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] test_sqlobject.py

[Oleg B. <ph...@ma...>]

On Mon, Dec 06, 2004 at 04:41:29PM +0300, Oleg Broytmann wrote:
> There is no column "driver". I will remove that part of the test in the
> trunk - we've decided to not allow non-columns keywords in .set().

   Commited at revision 447.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Postgres 7.2 and test_sqlobject.py

[Oleg B. <ph...@ph...>]

Hello!

   I created another private branch and commited my changes for Postgres
7.2:
http://svn.colorstudy.com/home/phd/SQLObject/postgres-7.2/sqlobject/postgres/pgconnection.py
   I added DROP SEQUENCE to dtopTable() and partially implemented
columnsFromSchemaOld().
   With this changes test_sqlobject.py gave only 3 failures! Two of them
are ALTER TABLE ... DROP COLUMN, which is unsupported by Postgres 7.2.
Unfixable.

   The third failure is
TypeError: Lazy.set() got an unexpected keyword argument driver
   in test_sqlobject.py, line 1160. Of course it must:

class Lazy(SQLObject):

    _lazyUpdate = True
    name = StringCol()
    other = StringCol(default='nothing')
    third = StringCol(default='third')

There is no column "driver". I will remove that part of the test in the
trunk - we've decided to not allow non-columns keywords in .set().
   But it is never too late to redecide ;)

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] OT: Programmers never die (was Re: Thanks Ian & Oleg!)

[Oleg B. <ph...@ma...>]

On Sun, Dec 05, 2004 at 11:57:29PM -0200, Jorge Luiz Godoy Filho wrote:
> Oleg Broytmann, Domingo, 5 de Dezembro de 2004 16:23, wrote:
> > Programmers don't die, they just GOSUB without RETURN.
> 
> Another good one:
> Programmers don't die, they just WHILE NOT EOF without NEXT
> ;-)

   Seen yesterday on /.: "Old programmers never die. They become
managers!" :-D

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Re: Thanks Ian & Oleg!

[Jorge L. G. F. <go...@ie...>]

Oleg Broytmann, Domingo, 5 de Dezembro de 2004 16:23, wrote:

> Programmers don't die, they just GOSUB without RETURN.

Another good one:

Programmers don't die, they just WHILE NOT EOF without NEXT


;-)


Be seeing you,
Godoy.

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Oleg B. <ph...@ma...>]

On Sun, Dec 05, 2004 at 01:42:39PM -0800, Scott Sanders wrote:
> Are you saying I should have a registry outside of the normal registry 
> process?

   Yes. Something like this:

class MyRegistry(ClassRegistry):
   def getClass(self, name):
      return SomethingAppropriate

class MyTable(SQLObject):
   _registry = MyRegistry()

columns = get_the_list_of_columns_from_the_db("my_table")
joins = get_the_list_of_joins_from_the_db("my_table")

for column in columns:
   MyTable.addColumn(column)

for join in joins:
   MyTable.addJoin(join)

Do you need anything besides that?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Scott S. <sc...@st...>]

Are you saying I should have a registry outside of the normal registry 
process?  I still want to be able to use all of SQLObjects methods 
normally.  There is nothing wrong with the master registry not knowing 
about my registry.  Something strikes me as wrong here.

Scott


On Dec 5, 2004, at 11:37 AM, Oleg Broytmann wrote:

> On Sun, Dec 05, 2004 at 11:21:41AM -0800, Scott Sanders wrote:
>> OK, then can I just get an addRegisrty() call
>
>    Every SQLObject has the attribute _registry. What do you want for
> addRegistry()?
>
> Oleg.
> -- 
>      Oleg Broytmann            http://phd.pp.ru/            
> ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss