Re: [SQLObject] varchar vs varchar(100) & re-running code under PythonWin

[Ben S. <sch...@pr...>]

Ok, here's a hack fix I threw in that works for both cases of VARCHAR 
and VARCHAR(n):
pgconnection.py:197
    def guessClass(self, t):
        if t.count('int'):
            return col.IntCol, {}
        elif t.count('varying'):
            if '(' in t:
                return col.StringCol, {'length': int(t[t.index('(')+1:-1])}
            return col.StringCol, {}
...continues

Now that it works I've discovered the frustration that I can only run a 
piece of SQLObject using code once in a session of PythonWin. After 
that, all subsequent executions will return the following:

Traceback (most recent call last):
  File 
"C:\Python24\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py", 
line 310, in RunScript
    exec codeObject in __main__.__dict__
  File "E:\develop\crm\sqlobjecttest.py", line 6, in ?
    class Entity(SQLObject):
  File "C:\Python24\Lib\site-packages\sqlobject\main.py", line 201, in 
__new__
    classregistry.registry(newClass._registry).addClass(newClass)
  File "C:\Python24\Lib\site-packages\sqlobject\classregistry.py", line 
71, in addClass
    raise ValueError(
AttributeError: 'module' object has no attribute '__file__'

I assume this is some module/global reload issue but it sure makes my 
debugging time consuming cause I have to shutdown PythonWin and reload 
all my environment again each execution session. No forgiveness here. 
Any ideas on how to address this?

    thanx & later,

       Ben Scherrey

Ian Bicking wrote:

> Ben Scherrey wrote:
>
>> Doh! You're right. Changing the specification of url to varchar(100) 
>> resolves the error. Is there something about SqlObject that requires 
>> a size specification? I'd hate to have to go into all my databases 
>> and define column sizes for every element in the table structures. 
>> Most all of my data is specified as straight varchar.
>
>
> I think it's a very thing, or maybe just a flaw in the method -- it 
> looks for types of "TEXT" but I believe Postgres prefers the name 
> "CHARACTER VARYING" and will return that type.
>
> Anyway, I added it to the unit tests, and a fix should come along later.
>