sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Unicode support?

[Max I. <ma...@uc...>]

Leif K-Brooks wrote:

> I'm working on a database-heavy Web application. I really like 
> SQLObject's features, so I would like to use it; unfortunately, the lack 
> of Unicode support is a real problem. I would imagine that this could be 
> fixed fairly easily by subclassing StrCol, but I'm really not familiar 
> enough with SQLObject's internals to do it myself. Has anyone else tried 
> that? Are there plans to natively support Unicode in SQLObject 0.6 or 
> later?

I have invented a rather crudge way to handle this:

def getstring(name):
     def getter(self):
         value = getattr(self, "_SO_get_" + name)()
         if type(value) == type(''):
             value = value.decode('utf8')
         return value
     return getter

def setstring(name):
     def setter(self, value):
         if type(value) == type(u''):
             value = value.encode('utf8')
         getattr(self, "_SO_set_" + name)(value)
     return setter


class User(SQLObject):
     name = StringCol(length=96, default='')

     _get_name = getstring('name')
     _set_name = setstring('name')

This solution provides convertion from Unicode (used throughout the 
probram) to the utf-8 encoding accepted by SQLObject.

Obviously, this is far from ideal. Therefore I'd like to see how the 
others deal with this problem.

Btw, Oleg's proposal about getting rid of sqlobject ad-hoc escaping can 
possibly solve the Unicode problem as well.

Re: [SQLObject] Unicode support?

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

On Tue, Nov 30, 2004 at 04:52:02AM -0500, Leif K-Brooks wrote:
> I'm working on a database-heavy Web application. I really like 
> SQLObject's features, so I would like to use it; unfortunately, the lack 
> of Unicode support is a real problem. I would imagine that this could be 
> fixed fairly easily by subclassing StrCol, but I'm really not familiar 
> enough with SQLObject's internals to do it myself. Has anyone else tried 

   We did that, but I cannot show the code - its a part of a commercial
program.

> that? Are there plans to natively support Unicode in SQLObject 0.6 or later?

   I don't know of any. And, btw, what is "unicode support"? Before
starting to implement "unicode support" we have to understand, what it
is.
   What are your use cases? In what encoding you are going to store
strings in the db? Should there be an attribute "encoding" on a column?
a table? a database? a db connection?

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

[SQLObject] Unicode support?

[Leif K-B. <eu...@ec...>]

I'm working on a database-heavy Web application. I really like 
SQLObject's features, so I would like to use it; unfortunately, the lack 
of Unicode support is a real problem. I would imagine that this could be 
fixed fairly easily by subclassing StrCol, but I'm really not familiar 
enough with SQLObject's internals to do it myself. Has anyone else tried 
that? Are there plans to natively support Unicode in SQLObject 0.6 or later?

[SQLObject] Memory leak?

[Martin d'A. <Mar...@s2...>]

Hi,

I think I have found a memory leak. I have a loop that inserts hundreds of 
thousands of rows in my table, and the memory usage grows eventhough I 
do not keep a handle to the instances I am creating. For example, the 
following program will use more memory when you tell it to store more rows 
in the database:

#!/usr/bin/env python

import sys
from sqlobject import *

class Persons(SQLObject):
    name = StringCol(length=4)

def create_table(conn):
    Persons._cacheValues = False
    Persons._connection = conn
    Persons.dropTable(ifExists=True)
    Persons.createTable()

def fill_table(size):
    for i in xrange(int(size)):
       p = Persons(name='Joe'+`i`)

if __name__ == '__main__':
    size = sys.argv[1]
    conn = connectionForURI('mysql://user:passwd@server/test')
    create_table(conn)
    fill_table(size)


At the prompt, just type "persons.py <number>". The bigger the 
<number>, the more memory is used. Is there a solution?

Martin

Re: [SQLObject] ._create() and .set()

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

Oleg Broytmann wrote:
> On Mon, Nov 29, 2004 at 09:47:03AM -0600, Ian Bicking wrote:
> 
>>Oleg Broytmann wrote:
>>
>>>SQLObject._create() performs separation of values based on
>>>self._SO_plainSetters, creating "forDB" and "others", and calling
>>>self.set(**forDB).
>>>
>>>  Is the separation really neccessary? self.set() does the same
>>>separation itself. Why not just pass all values to self.set()?
>>
>>I think you're right, there's no real reason for this split.  It 
>>probably is left over from a (much) earlier time when the code didn't 
>>use .set while doing inserts (before _SO_creating).
> 
> 
>    Well, there is a minor semantic difference. ._create() tests if all
> passed keywords arguments are actually columns. .set() does not test it.
> One can do self.set(noncolumn="value"), which results in assignment
> self.noncolumn="value", but can't do ATable(noncolumn="value").
> 
>    Should we change the semantic of .set(), so it does not allow
> non-column keywords? In my opinion - yes, we should.

Yes, it's just an oversight that it doesn't check them.

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

Re: [SQLObject] ._create() and .set()

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

On Mon, Nov 29, 2004 at 09:47:03AM -0600, Ian Bicking wrote:
> Oleg Broytmann wrote:
> >SQLObject._create() performs separation of values based on
> >self._SO_plainSetters, creating "forDB" and "others", and calling
> >self.set(**forDB).
> >
> >   Is the separation really neccessary? self.set() does the same
> >separation itself. Why not just pass all values to self.set()?
> 
> I think you're right, there's no real reason for this split.  It 
> probably is left over from a (much) earlier time when the code didn't 
> use .set while doing inserts (before _SO_creating).

   Well, there is a minor semantic difference. ._create() tests if all
passed keywords arguments are actually columns. .set() does not test it.
One can do self.set(noncolumn="value"), which results in assignment
self.noncolumn="value", but can't do ATable(noncolumn="value").

   Should we change the semantic of .set(), so it does not allow
non-column keywords? In my opinion - yes, we should.

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

On Mon, Nov 29, 2004 at 03:07:41PM -0600, Ian Bicking wrote:
> Oleg Broytmann wrote:
> >On Mon, Nov 29, 2004 at 12:24:50PM -0600, Ian Bicking wrote:
> >
> >>You could cache the result, but in many cases that query need never be 
> >>run, so it shouldn't happen on instantiation.
> >
> >   What about the attached version?
> 
> Yes, that looks good.

   Commited.

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

Oleg Broytmann wrote:
> On Mon, Nov 29, 2004 at 12:24:50PM -0600, Ian Bicking wrote:
> 
>>You could cache the result, but in many cases that query need never be 
>>run, so it shouldn't happen on instantiation.
> 
> 
>    What about the attached version?

Yes, that looks good.

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

On Mon, Nov 29, 2004 at 12:24:50PM -0600, Ian Bicking wrote:
> You could cache the result, but in many cases that query need never be 
> run, so it shouldn't happen on instantiation.

   What about the attached version?

> I just fixed this one today, if you svn up it should be gone.

   Yes, that fixed the problem.

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

On Mon, Nov 29, 2004 at 12:47:32PM -0600, Ian Bicking wrote:
> >http://svn.colorstudy.com/home/phd/SQLObject/inheritance/tests/test_sqlobject.py
> >
> >PS. I renamed test.py to test_sqlobject.py to import from it.
> 
> Thanks; if you want to merge that over into the trunk, please do.  The 
> rename is probably a good idea.

   Done.

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

Oleg Broytmann wrote:
> On Mon, Nov 29, 2004 at 12:31:31PM -0600, Ian Bicking wrote:
> 
>>python test.py -dpostgres
>>it's not very flexible with its command-line arguments.
> 
> 
>    I've made it much more flexible using getopt. Please look at main() at
> 
> http://svn.colorstudy.com/home/phd/SQLObject/inheritance/tests/test_sqlobject.py
> 
> PS. I renamed test.py to test_sqlobject.py to import from it.

Thanks; if you want to merge that over into the trunk, please do.  The 
rename is probably a good idea.

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

On Mon, Nov 29, 2004 at 12:31:31PM -0600, Ian Bicking wrote:
> python test.py -dpostgres
> it's not very flexible with its command-line arguments.

   I've made it much more flexible using getopt. Please look at main() at

http://svn.colorstudy.com/home/phd/SQLObject/inheritance/tests/test_sqlobject.py

PS. I renamed test.py to test_sqlobject.py to import from it.

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

Oleg Broytmann wrote:
> On Mon, Nov 29, 2004 at 12:03:03PM -0600, Ian Bicking wrote:
> 
>>>PS. After fixing it I've got an amazing number of exceptions and
>>>failures during the test. It seems no one has ran the test suite for
>>>quite some time, at least on Postgres!
>>
>>I was just running it without problems.
> 
> 
>    BTW, how have yoy ran it at all?
> 
> $ python -O test.py -d postgres

python test.py -dpostgres
it's not very flexible with its command-line arguments.

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

Oleg Broytmann wrote:
> On Mon, Nov 29, 2004 at 12:03:03PM -0600, Ian Bicking wrote:
> 
>>Can you move the server version into a method (serverVersion())
> 
> 
>    Certainly I can... but why? You'd like to ask the same version again
> and again?
>    Or you want to ask for the version only one, but not in __init__? In
> the latter case it'd be better to implemen it as a property.

You could cache the result, but in many cases that query need never be 
run, so it shouldn't happen on instantiation.

>>>PS. After fixing it I've got an amazing number of exceptions and
>>>failures during the test. It seems no one has ran the test suite for
>>>quite some time, at least on Postgres!
>>
>>I was just running it without problems.  Actually there's a transaction 
>>problem that only occurs when I run all the tests in sequence, and I 
>>don't understand it.  But otherwise it's fine.  Maybe it's more problems 
>>with 7.2?
> 
> 
>    I think so. The first problem is
> 
> ERROR: testClassCreate (__main__.AutoTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "test_sqlobject.py", line 700, in testClassCreate
>     class AutoTest(SQLObject):
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 225, in __new__
>     newClass.addColumnsFromDatabase()
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 593, in addColumnsFromDatabase
>     for columnDef in conn.columnsFromSchema(cls._table, cls):
>   File "pgconnection.py", line 151, in columnsFromSchema
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 218, in queryAll
>     return self._runWithConnection(self._queryAll, s)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection
>     val = meth(conn, *args)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 211, in _queryAll
>     self._executeRetry(conn, c, s)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry
>     return cursor.execute(query)
> ProgrammingError: ERROR:  parser: parse error at or near "("
> 
> 
>         SELECT pg_catalog.pg_get_constraintdef(oid) as condef
>         FROM pg_catalog.pg_constraint r
>         WHERE r.conrelid = 'auto_test'::regclass AND r.contype = 'f'

I don't believe there's any "pg_catalog" in 7.2; I believe pg_catalog is 
a schema (a separate table/function namespace), and schemas weren't 
introduced until after 7.2.  In that case, maybe just removing 
"pg_catalog." will fix it (if the version is 7.2).

> And most other exceptions are, probably, the result of unclean exit from the method:
> 
> ERROR: testGet (__main__.DeleteSelectTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/local/src/SQL/SQLObject-inheritance/tests/SQLObjectTest.py", line 144, in setUp
>     c.createTable(ifNotExists=True)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 1161, in createTable
>     conn.createTable(cls)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 349, in createTable
>     self.query(self.createTableSQL(soClass))
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 205, in query
>     return self._runWithConnection(self._query, s)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection
>     val = meth(conn, *args)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 202, in _query
>     self._executeRetry(conn, conn.cursor(), s)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry
>     return cursor.execute(query)
> ProgrammingError: ERROR:  Relation 'test_s_o1_id_seq' already exists
> 
> CREATE TABLE test_s_o1 (
>     id SERIAL PRIMARY KEY,
>     passwd VARCHAR(10),
>     name_col VARCHAR(50)
> )

That's must be something left over; generally I haven't had problems 
with that (the tests are supposed to clean up after themselves), but it 
could happen.

>    except for the only failure:
> 
> FAIL: Raise an error if a class is defined more than once.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "test_sqlobject.py", line 37, in testErrorOnDuplicateClassDefinition
>     self.assertEqual(str(err), "class Duplicate is already in the registry")
>   File "/usr/local/lib/python2.3/unittest.py", line 302, in failUnlessEqual
>     raise self.failureException, \
> AssertionError: "class Duplicate is already in the registry (other class is <class '__main__.Duplicate'>, from the module __main__ in test_sqlobject.py; attempted new class is <class '__main__.Duplicate'>, from the module __main__ in test_sqlobject.py)" != 'class Duplicate is already in the registry'

I just fixed this one today, if you svn up it should be gone.

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

On Mon, Nov 29, 2004 at 12:03:03PM -0600, Ian Bicking wrote:
> >PS. After fixing it I've got an amazing number of exceptions and
> >failures during the test. It seems no one has ran the test suite for
> >quite some time, at least on Postgres!
> 
> I was just running it without problems.

   BTW, how have yoy ran it at all?

$ python -O test.py -d postgres
Traceback (most recent call last):
  File "test.py", line 1372, in ?
    setDatabaseType(db)
  File "/usr/local/src/SQL/SQLObject/tests/SQLObjectTest.py", line 174,
in setDatabaseType
    raise KeyError, 'No connection by the type %s is known' % t
KeyError: 'No connection by the type  is known'

   Of course.

        if arg.startswith('-d'):
            dbs.append(arg[2:])

   dbs is now [["postgres"]] instead of ["postgres"].

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

On Mon, Nov 29, 2004 at 12:03:03PM -0600, Ian Bicking wrote:
> Can you move the server version into a method (serverVersion())

   Certainly I can... but why? You'd like to ask the same version again
and again?
   Or you want to ask for the version only one, but not in __init__? In
the latter case it'd be better to implemen it as a property.

> >PS. After fixing it I've got an amazing number of exceptions and
> >failures during the test. It seems no one has ran the test suite for
> >quite some time, at least on Postgres!
> 
> I was just running it without problems.  Actually there's a transaction 
> problem that only occurs when I run all the tests in sequence, and I 
> don't understand it.  But otherwise it's fine.  Maybe it's more problems 
> with 7.2?

   I think so. The first problem is

ERROR: testClassCreate (__main__.AutoTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_sqlobject.py", line 700, in testClassCreate
    class AutoTest(SQLObject):
  File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 225, in __new__
    newClass.addColumnsFromDatabase()
  File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 593, in addColumnsFromDatabase
    for columnDef in conn.columnsFromSchema(cls._table, cls):
  File "pgconnection.py", line 151, in columnsFromSchema
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 218, in queryAll
    return self._runWithConnection(self._queryAll, s)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection
    val = meth(conn, *args)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 211, in _queryAll
    self._executeRetry(conn, c, s)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry
    return cursor.execute(query)
ProgrammingError: ERROR:  parser: parse error at or near "("


        SELECT pg_catalog.pg_get_constraintdef(oid) as condef
        FROM pg_catalog.pg_constraint r
        WHERE r.conrelid = 'auto_test'::regclass AND r.contype = 'f'


And most other exceptions are, probably, the result of unclean exit from the method:

ERROR: testGet (__main__.DeleteSelectTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/src/SQL/SQLObject-inheritance/tests/SQLObjectTest.py", line 144, in setUp
    c.createTable(ifNotExists=True)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 1161, in createTable
    conn.createTable(cls)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 349, in createTable
    self.query(self.createTableSQL(soClass))
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 205, in query
    return self._runWithConnection(self._query, s)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection
    val = meth(conn, *args)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 202, in _query
    self._executeRetry(conn, conn.cursor(), s)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry
    return cursor.execute(query)
ProgrammingError: ERROR:  Relation 'test_s_o1_id_seq' already exists

CREATE TABLE test_s_o1 (
    id SERIAL PRIMARY KEY,
    passwd VARCHAR(10),
    name_col VARCHAR(50)
)

   except for the only failure:

FAIL: Raise an error if a class is defined more than once.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_sqlobject.py", line 37, in testErrorOnDuplicateClassDefinition
    self.assertEqual(str(err), "class Duplicate is already in the registry")
  File "/usr/local/lib/python2.3/unittest.py", line 302, in failUnlessEqual
    raise self.failureException, \
AssertionError: "class Duplicate is already in the registry (other class is <class '__main__.Duplicate'>, from the module __main__ in test_sqlobject.py; attempted new class is <class '__main__.Duplicate'>, from the module __main__ in test_sqlobject.py)" != 'class Duplicate is already in the registry'

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

Oleg Broytmann wrote:
> On Mon, Nov 29, 2004 at 10:58:26AM -0600, Ian Bicking wrote:
> 
>>Maybe we have to do a version check on the pg server, though 
> 
> 
>    The atached patch does the job. I can commit it, if no one objects.

Can you move the server version into a method (serverVersion()), and use 
an if statement in dropTable (instead of or/and conditionals)?

> PS. After fixing it I've got an amazing number of exceptions and
> failures during the test. It seems no one has ran the test suite for
> quite some time, at least on Postgres!

I was just running it without problems.  Actually there's a transaction 
problem that only occurs when I run all the tests in sequence, and I 
don't understand it.  But otherwise it's fine.  Maybe it's more problems 
with 7.2?

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

[SQLObject] Re: Postgres: DROP table CASCADE

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

On Mon, Nov 29, 2004 at 10:58:26AM -0600, Ian Bicking wrote:
> Maybe we have to do a version check on the pg server, though 

   The atached patch does the job. I can commit it, if no one objects.

PS. After fixing it I've got an amazing number of exceptions and
failures during the test. It seems no one has ran the test suite for
quite some time, at least on Postgres!

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

[SQLObject] Re: Postgres: DROP table CASCADE

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

On Mon, Nov 29, 2004 at 10:58:26AM -0600, Ian Bicking wrote:
> Maybe we have to do a version check on the pg server, though 
> I'm not really sure how to do that (some pg_ table, I guess).

   SELECT version();

The result string is probably too version-dependent, I am afraid. My is

# SELECT version();
                            version
---------------------------------------------------------------
 PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.95.4
(1 row)

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

RE: [SQLObject] Postgres: DROP table CASCADE

[<jws...@ra...>]

We need to check for version >= 7.3.0

E.17. Release 7.3

    Release date: 2002-11-27

E.17.1. Overview

Major changes in this release:

    PostgreSQL now records object dependencies, which allows improvements in
many areas. DROP statements now take either CASCADE or RESTRICT to control
whether dependent objects are also dropped. 

Re: [SQLObject] Postgres: DROP table CASCADE

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

On Mon, Nov 29, 2004 at 12:04:26PM -0500, Justin Azoff wrote:
> On Mon, 2004-11-29 at 11:55, Oleg Broytmann wrote:
> >    AFAII Postgres does not support CASCADE. Exactly opposite - it is
> > MySQL who supports it... to some extent. MySQL silently ignores CASCADE.
> > But Postgres actively opposes it.
> 
> it doesn't ?
> http://www.postgresql.org/docs/7.4/static/sql-droptable.html
> 
> Synopsis
> DROP TABLE name [, ...] [ CASCADE | RESTRICT ]

   I use 7.2:

Synopsis

 DROP TABLE name [, ...]

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

Re: [SQLObject] Re: Postgres: DROP table CASCADE

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

On Mon, Nov 29, 2004 at 10:58:26AM -0600, Ian Bicking wrote:
> What version of Postgres are you using?

   7.2 (7.2.1 - this is Debian GNU/Linux 3.0).

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

Re: [SQLObject] Postgres: DROP table CASCADE

[Justin A. <JA...@ua...>]

On Mon, 2004-11-29 at 11:55, Oleg Broytmann wrote:
>    AFAII Postgres does not support CASCADE. Exactly opposite - it is
> MySQL who supports it... to some extent. MySQL silently ignores CASCADE.
> But Postgres actively opposes it.

it doesn't ?
http://www.postgresql.org/docs/7.4/static/sql-droptable.html

Synopsis
DROP TABLE name [, ...] [ CASCADE | RESTRICT ]

-- 
-- Justin Azoff
-- Network Performance Analyst

[SQLObject] Re: Postgres: DROP table CASCADE

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

What version of Postgres are you using?  This might be a version issue 
there, as I'm pretty sure at least some versions of Postgres support 
CASCADE.  Maybe we have to do a version check on the pg server, though 
I'm not really sure how to do that (some pg_ table, I guess).

Oleg Broytmann wrote:
> Traceback (most recent call last):
>   File "/usr/local/src/SQL/SQLObject-inheritance/tests/SQLObjectTest.py", line 131, in setUp
>     c.dropTable(ifExists=True, cascade=True)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 1150, in dropTable
>     conn.dropTable(cls._table, cascade)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/postgres/pgconnection.py", line 96, in dropTable
>     self.query("DROP TABLE %s %s" % (tableName,
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 205, in query
>     return self._runWithConnection(self._query, s)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection
>     val = meth(conn, *args)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 202, in _query
>     self._executeRetry(conn, conn.cursor(), s)
>   File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry
>     return cursor.execute(query)
> ProgrammingError: ERROR:  parser: parse error at or near "CASCADE"
> 
> DROP TABLE so_validation CASCADE
> 
>    AFAII Postgres does not support CASCADE. Exactly opposite - it is
> MySQL who supports it... to some extent. MySQL silently ignores CASCADE.
> But Postgres actively opposes it.
> 
>    Can I remove dropTable() from sqlobject/postgres/pgconnection.py in
> the trunk?
> 
> Oleg.

[SQLObject] Postgres: DROP table CASCADE

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

Traceback (most recent call last):
  File "/usr/local/src/SQL/SQLObject-inheritance/tests/SQLObjectTest.py", line 131, in setUp
    c.dropTable(ifExists=True, cascade=True)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/main.py", line 1150, in dropTable
    conn.dropTable(cls._table, cascade)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/postgres/pgconnection.py", line 96, in dropTable
    self.query("DROP TABLE %s %s" % (tableName,
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 205, in query
    return self._runWithConnection(self._query, s)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 126, in _runWithConnection
    val = meth(conn, *args)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 202, in _query
    self._executeRetry(conn, conn.cursor(), s)
  File "/usr/local/lib/python2.3/site-packages/sqlobject/dbconnection.py", line 197, in _executeRetry
    return cursor.execute(query)
ProgrammingError: ERROR:  parser: parse error at or near "CASCADE"

DROP TABLE so_validation CASCADE

   AFAII Postgres does not support CASCADE. Exactly opposite - it is
MySQL who supports it... to some extent. MySQL silently ignores CASCADE.
But Postgres actively opposes it.

   Can I remove dropTable() from sqlobject/postgres/pgconnection.py in
the trunk?

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