sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Preparing for 0.4

[Mike H. <th...@bi...>]

On Tue, Apr 22, 2003 at 10:11:33PM -0700, David M. Cook wrote:
> There's a bogus couple of lines (544-5) in the 
> DBConnection.PosgresConnection.guessClass method I submitted:
> 
>         elif t.startswith('datetime'):
> 	    return Col.DateTimeCol, {}
> 
> that were just copied from the old guessClass method.  Since Postgres
> doesn't have antyhing that matches 'datetime' AFAIK, this doesn't do
> anything.  I haven't had a chance to look at how date handling is done, so I
> don't know if changing this to something like:

In PostgreSQL < 7.3, 'datetime' is the same as 'timestamp'.  In
PostgreSQL >= 7.3, it has been depreicated.

-- mikeh

Re: [SQLObject] Preparing for 0.4

[David M. C. <da...@da...>]

On Mon, Apr 21, 2003 at 10:16:12PM -0500, Ian Bicking wrote:

> I'm planning on putting 0.4 out before too long.  I've added Styles and
> taken out the lazy fetching.  There are a bunch of updates I want/need
> to do to the documentation, but besides that I don't have any big plans
> -- stuff like constraints (on the Python side) will wait.  
> 
> I might have missed something, though.  Is there any unresolved issues
> that should be dealt with before 0.4?

There's a bogus couple of lines (544-5) in the 
DBConnection.PosgresConnection.guessClass method I submitted:

        elif t.startswith('datetime'):
	    return Col.DateTimeCol, {}

that were just copied from the old guessClass method.  Since Postgres
doesn't have antyhing that matches 'datetime' AFAIK, this doesn't do
anything.  I haven't had a chance to look at how date handling is done, so I
don't know if changing this to something like:

      elif t.startswith('date') or t.startswith('time'):
      	   return Col.DateTimeCol, {}
	   
is useful or not.

Dave

Re: [SQLObject] Preparing for 0.4

[Peter W. <pw-...@te...>]

On Tuesday, April 22, 2003, at 01:16  PM, Ian Bicking wrote:

> I might have missed something, though.  Is there any unresolved issues
> that should be dealt with before 0.4?
>

I've been doing some more work with SQLite and come up with the 
following that might be useful to have.

class SQLiteConnection(DBAPI):

     def __init__(self, dsn, autoCommit=1, **kw):
         assert sqlite, 'sqlite module cannot be found'
         self.dsn = dsn  # full path to sqlite-db-file
         if not autoCommit and not kw.has_key('pool'):
             # Pooling doesn't work with transactions...
             kw['pool'] = 0
         # use only one connection for sqlite - supports multiple 
cursors per connection
         self._conn = sqlite.connect(self.dsn)
         DBAPI.__init__(self, **kw)

     def makeConnection(self):
         return self._conn

The autoCommit=1 and the pooling conditional is just copied directly 
from PostgresConnection, SQLite supports transactions so I presume that 
for the same reasons this is needed.

I changed how it deals with getting a connection so that code like the 
following will work without needing to turn the results into lists, 
really any code where you have database access inside loops like this 
not just deletes.

users = User.select('all')
for i in users:
     for ul in u.userLocations:
         ul.destroySelf()

SQLite + Python only supports one connection at a time. In my 
understanding the select loop should be able to run in a different 
connection to the delete as SQLite only locks when changing the db. I'm 
trying to find out exactly where the oddness is happening.

Can you see any problems with doing this?

--
peter w.

Re: [SQLObject] Preparing for 0.4

[Peter W. <pw-...@te...>]

On Tuesday, April 22, 2003, at 01:16  PM, Ian Bicking wrote:

> I'm planning on putting 0.4 out before too long.  I've added Styles and
> taken out the lazy fetching.  There are a bunch of updates I want/need
> to do to the documentation, but besides that I don't have any big plans
> -- stuff like constraints (on the Python side) will wait.  
>
> I might have missed something, though.  Is there any unresolved issues
> that should be dealt with before 0.4?

A small addition to the docs  - in the section 'Selecting Multiple 
Objects' adding a quick note about .select('all') could be useful, I 
found this in the example and pretty sure its not mentioned anywhere in 
either the SQLObject or SQLBuilder docs.

--
peter w.

Re: [SQLObject] foreign key, string vs. object, circular references...

[Luke O. <lu...@me...>]

Hmmmm indeed. I really don't like a solution that makes maintaining
tablenames more than just editing the specific class. And I wouldn't
like to have to support this list hack in the future when we have a
better method. So for now, I'd say hold off on being able to create
with the "references" SQL.

(Admittedly, our use of SQLObject is leading to moving constraints
like 'references' out of the database and into SQLObject. So it's
less of an issue to me. But at the same time, a 'references'
constraint has only ever been truly useful to me if i'm also able to
set "ON DELETE/UPDATE ...", which i'm not sure how you're going to
get into SQLObject right now.)

- Luke

> Hmmmm..  So what about a not overly elegant solution to createTable
> with foreign keys that works for the time being.  Something like:
>
> In Col.py, _extraSQL:
>
>
>  if self.foreignKey:
>     if type(self.foreignKey) == type([]):
>       foreignTableSQLName = foreingKey[1]
>     else:
>       foreignTableSQLName = SQLNameFromClassName(self.foreignKey)
>     result.append('REFERENCES %s') % foreignTableSQLName

Re: [SQLObject] foreign key, string vs. object, circular references...

[Bud P. B. <bu...@si...>]

Thanks, Luke, for the explanation and insight.

Hmmmm..  So what about a not overly elegant solution to createTable
with foreign keys that works for the time being.  Something like:

In Col.py, _extraSQL:


 if self.foreignKey:
    if type(self.foreignKey) == type([]):
      foreignTableSQLName = foreingKey[1]
    else:
      foreignTableSQLName = SQLNameFromClassName(self.foreignKey)
    result.append('REFERENCES %s') % foreignTableSQLName

If the table name is automatically derived from the class name, the
foreignKey keyword argument is used as usual.  If not, foreignKey
takes a list where the second element is the table name that was
(redundantly) already given in _table.  

SQLNameFromClassName is a placeholder for the real conversion routine
that I didn't find quickly enough...

As announced before, not elegant (mainly because of redundancy and
probably difficult to use), but it should work...

what do you think?


On Tue, 22 Apr 2003 10:52:00 -0500
Luke Opperman <lu...@me...> wrote:

> 
> >     Pass a string with foreignKey, not the actual class. This
> > avoids
> >     circular dependencies.
> >
> > Really, it would be great to have the actual class instead of a
> > string
> > here.  That way, it would be trivial to find out the table name...
> > What exactly are the problems of circular dependencies?  In the
> > person, phonenumber example, I see that phonenumber would reference
> > person, but I don't see any reference back from person to
> > phonenumber.
> 
> Circular dependencies are a very real issue, I mentioned in an email a
> while back that classRegistry and needSet don't completely solve this
> issue either, but...
> 
> Circular dependency happens when you have a foreignKey in one class,
> and in the linked class a MultipleJoin back to the first class. If
> you specify by class instead of name, that means you need to import
> the other class in each:
> 
> Class A: import Class B (for foreignKey)
> leads to
> Class B: import Class A (for join)
> 
> and Python blows up ("unable to import Class A") because it's already
> in the midst of importing class A.
> 
> Specifying by string solves half this problem, but still leads to the
> issue where a third module (SQLObject-derived or not) imports Class
> A, then accesses the foreignKey, and SO.classRegistry has not heard
> of Class B yet. So this third module (which should not really have to
> know about class B's specific location at all) has to import class B.
> I haven't found a good solution to this problem. Here's one
> possibility however:
> 
> Since the circular dependency problem is with imports that happen at
> *module import* time, it would be conceivable to add a delayed import
> feature, so that when an SQLObject is *instantiated* any remaining
> classes are imported, and therefore put into needSet. Perhaps
> something like:
> 
> class B(SQLObject):
>     _imports = ['Objects.A','OtherObjects.C']
> 
> This would have the requirement that no SQLObject-derived class
> *explicitly* import any other SQLObjects, only through this
> mechanism. It's not pretty, but I'm really cringing at our current
> situation where a class that only directly deals with one or two
> SQLObject classes is needing to import everything those join or key
> to (and those others join or key to, and....) Ugh.
> 
> (In our case, all the SQLObjects for a given app reside in one
> directory, so a really easy fix would be to have
> classRegistry/needSet attempt to import those it doesn't have yet
> from the directory of the class being called. But that's not a very
> flexible alternative, so I'll ignore it. But if everyone else does
> things that way too, then perhaps we can have needSet at least
> attempt this... this gets back to my suggestion for multiple
> classRegistry's as well.)
> 
> - Luke
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> 


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------

Re: [SQLObject] foreign key, string vs. object, circular references...

[Luke O. <lu...@me...>]

>     Pass a string with foreignKey, not the actual class. This
> avoids
>     circular dependencies.
>
> Really, it would be great to have the actual class instead of a
> string
> here.  That way, it would be trivial to find out the table name...
> What exactly are the problems of circular dependencies?  In the
> person, phonenumber example, I see that phonenumber would reference
> person, but I don't see any reference back from person to
> phonenumber.

Circular dependencies are a very real issue, I mentioned in an email a
while back that classRegistry and needSet don't completely solve this
issue either, but...

Circular dependency happens when you have a foreignKey in one class,
and in the linked class a MultipleJoin back to the first class. If
you specify by class instead of name, that means you need to import
the other class in each:

Class A: import Class B (for foreignKey)
leads to
Class B: import Class A (for join)

and Python blows up ("unable to import Class A") because it's already
in the midst of importing class A.

Specifying by string solves half this problem, but still leads to the
issue where a third module (SQLObject-derived or not) imports Class
A, then accesses the foreignKey, and SO.classRegistry has not heard
of Class B yet. So this third module (which should not really have to
know about class B's specific location at all) has to import class B.
I haven't found a good solution to this problem. Here's one
possibility however:

Since the circular dependency problem is with imports that happen at
*module import* time, it would be conceivable to add a delayed import
feature, so that when an SQLObject is *instantiated* any remaining
classes are imported, and therefore put into needSet. Perhaps
something like:

class B(SQLObject):
    _imports = ['Objects.A','OtherObjects.C']

This would have the requirement that no SQLObject-derived class
*explicitly* import any other SQLObjects, only through this
mechanism. It's not pretty, but I'm really cringing at our current
situation where a class that only directly deals with one or two
SQLObject classes is needing to import everything those join or key
to (and those others join or key to, and....) Ugh.

(In our case, all the SQLObjects for a given app reside in one
directory, so a really easy fix would be to have
classRegistry/needSet attempt to import those it doesn't have yet
from the directory of the class being called. But that's not a very
flexible alternative, so I'll ignore it. But if everyone else does
things that way too, then perhaps we can have needSet at least
attempt this... this gets back to my suggestion for multiple
classRegistry's as well.)

- Luke

[SQLObject] foreign key, string vs. object, circular references...

[Bud P. B. <bu...@si...>]

Ian,

I'm looking whether there is a solution to creating clean SQL for
Postgres and Foreign Keys that could still make it into 0.4.

In the documentation, you write: about foreignKeys:

    Pass a string with foreignKey, not the actual class. This avoids
    circular dependencies.

Really, it would be great to have the actual class instead of a string
here.  That way, it would be trivial to find out the table name...
What exactly are the problems of circular dependencies?  In the
person, phonenumber example, I see that phonenumber would reference
person, but I don't see any reference back from person to phonenumber.  

Thanks

--b


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------

Re: [SQLObject] change to Col.py

[Bud P. B. <bu...@si...>]

Actually, a better (or more correct fix) would be the following:

def _extraSQL(self):
  result = []
  if self.notNull or self.alternateID:
    result.append('NOT NULL')
  if self.unique or self.alternateID:
    result.append('UNIQUE')
  return result

This is the correct way that alternateID implies NOT NULL.

--b

On Tue, 22 Apr 2003 12:31:56 +0200
"Bud P. Bruegger" <bu...@si...> wrote:

> Ian, 
> 
> I double checked the patches I sent and found that you didn't apply
> one of my fixes in CVS:
> 
> Col.py, in _extraSQL:  instead of 
> 
>   if self.unique or self.alternateID:
>     result.append('UNIQUE')
> 
> it would be better to state:
>     
>   if self.unique or self.alternateID:
>     result.append('UNIQUE')
>     result.append('NOT NULL')
> 
> At least in my understanding of PostgreSQL, UNIQUE does not seem to
> imply NOT NULL.  
> 
> --b
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> 


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------

[SQLObject] change to Col.py

[Bud P. B. <bu...@si...>]

Ian, 

I double checked the patches I sent and found that you didn't apply
one of my fixes in CVS:

Col.py, in _extraSQL:  instead of 

  if self.unique or self.alternateID:
    result.append('UNIQUE')

it would be better to state:
    
  if self.unique or self.alternateID:
    result.append('UNIQUE')
    result.append('NOT NULL')

At least in my understanding of PostgreSQL, UNIQUE does not seem to
imply NOT NULL.  

--b

Re: [SQLObject] TextCol

[Bud P. B. <bu...@si...>]

On 18 Apr 2003 20:09:19 -0500
Ian Bicking <ia...@co...> wrote:

> On Fri, 2003-04-18 at 15:58, Luke Opperman wrote:
> > For those who like things more explicit, I was asked to create a
> > forced TextCol (instead of letting StringCol handle both cases).
> 
> I can't decide... use SQL terminology (like TEXT), or Python terminology
> (like string)... for instance: notNull, notNone, or required?  One
> string column with multiple SQL implementations (CHAR, VARCHAR, and
> TEXT)?  And Python's strings can also be BLOBs... and XMLRPC needs
> Binary types to distinguish... and someday Python is supposed to
> distinguish between text and binary data...

On the philosphy of naming:  After proposing notNone instead of
NotNull to avoid SQL terminology, I've changed my mind and believe it
is ok to use full SQL terminology in the _column definition.  After
all, this is to decide about a physical representation in the backend.
As Ian points out, totally automatic mappings are not always optimal.  

This leaves the question on whether non-SQL backends, such as DBM or
potentially MetaKit can live with the SQL-specific
terminology/concepts...  

--b


> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> 


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------

[SQLObject] Preparing for 0.4

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

I'm planning on putting 0.4 out before too long.  I've added Styles and
taken out the lazy fetching.  There are a bunch of updates I want/need
to do to the documentation, but besides that I don't have any big plans
-- stuff like constraints (on the Python side) will wait.  

I might have missed something, though.  Is there any unresolved issues
that should be dealt with before 0.4?


-- 
Ian Bicking  ia...@co...  http://colorstudy.com
4869 N. Talman Ave., Chicago, IL 60625  /  773-275-7241
"There is no flag large enough to cover the shame of 
 killing innocent people" -- Howard Zinn

Re: [SQLObject] SQLBuilder.const: parens get tacked on in insert?

[David M. C. <da...@da...>]

On Mon, Apr 21, 2003 at 02:43:00AM -0500, Ian Bicking wrote:

> Oh, yes, that explains it.  I put in a line to fix that (in CVS), at
> least for the case of SQLBuilder consts... maybe the callable() stuff

Great, using SQLBuilder.const works for defaults now.  I submitted a patch
for this (also fixes the regexp that got munged.)

Dave

Re: [SQLObject] SQLBuilder.const: parens get tacked on in insert?

[David M. C. <da...@da...>]

On Mon, Apr 21, 2003 at 02:43:00AM -0500, Ian Bicking wrote:

> Oh, yes, that explains it.  I put in a line to fix that (in CVS), at
> least for the case of SQLBuilder consts... maybe the callable() stuff
> should be taken out, and you just use a different keyword argument for
> dynamic defaults... 

Time to start checking out from CVS, then!

Perhaps the implementation of a __call__ method could be moved down lower in
the SQLExpression class hierarchy?

Dave

Re: [SQLObject] SQLBuilder.const: parens get tacked on in insert?

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

On Sat, 2003-04-19 at 19:46, David M. Cook wrote:
> I solved this for now by commenting out 
> 
>         elif callable(self._default):
>             return self._default()
> 
> in Col.py.  However, I suspect just commenting out code is just a good way
> to get into trouble later ;}

Oh, yes, that explains it.  I put in a line to fix that (in CVS), at
least for the case of SQLBuilder consts... maybe the callable() stuff
should be taken out, and you just use a different keyword argument for
dynamic defaults... 

  Ian

Re: [SQLObject] SQLBuilder.const: parens get tacked on in insert?

[David M. C. <da...@da...>]

On Fri, Apr 18, 2003 at 08:01:04PM -0700, David M. Cook wrote:

> In my quest to get default values out of the Postgres metadata (the default
> values are given as a string representation), SQLBuilder.const would see the
> best way to go (since some things can't be eval'ed).  For instance,

I solved this for now by commenting out 

        elif callable(self._default):
            return self._default()

in Col.py.  However, I suspect just commenting out code is just a good way
to get into trouble later ;}

Dave

[SQLObject] SQLBuilder.const: parens get tacked on in insert?

[David M. C. <da...@da...>]

In my quest to get default values out of the Postgres metadata (the default
values are given as a string representation), SQLBuilder.const would see the
best way to go (since some things can't be eval'ed).  For instance,
Postgress represents a default of "current_date" internally as
"('now'::text)::date":

>>> from SQLObject.SQLBuilder import *
>>> now = getattr(const, "('now'::text)::date")
>>> now
('now'::text)::date
>>> two = getattr(const, '2')
>>> two
2
>>> foo = getattr(const, "'foo'")
>>> foo
'foo'

So far seems just what I need.

However at object creation time the constants all get parens tacked onto
them, e.g:

INSERT INTO disc_info (purchase_date, shelf_space, disc_count, disc_id,
release_year, media_id, disc_title, price, lent_to, comments, id) VALUES
(('now'::text)::date(), 1.0(), 1(), 3, '1996', NULL, '', '10.00'(), '', '', 3)

Setting a value manually in the new statement does work as expected:

di = DiscInfo.new(disc=disc, 
purchaseDate=getattr(SQLBuilder.const, "('now'::text)::date"), 
shelfSpace=getattr(SQLBuilder.const, '1'),
discTitle='', releaseYear='1996', media=None, lentTo='', comments='')
		  
results in

INSERT INTO disc_info (shelf_space, media_id, disc_count, disc_id,
release_year, purchase_date, disc_title, price, lent_to, comments, id)
VALUES (1, NULL, 1(), 3, '1996', ('now'::text)::date, '', '10.00'(), '', '',
6)

Do I misunderstand SQLBuilder.const?

Dave Cook

Re: [SQLObject] TextCol

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

On Fri, 2003-04-18 at 15:58, Luke Opperman wrote:
> For those who like things more explicit, I was asked to create a
> forced TextCol (instead of letting StringCol handle both cases).

I can't decide... use SQL terminology (like TEXT), or Python terminology
(like string)... for instance: notNull, notNone, or required?  One
string column with multiple SQL implementations (CHAR, VARCHAR, and
TEXT)?  And Python's strings can also be BLOBs... and XMLRPC needs
Binary types to distinguish... and someday Python is supposed to
distinguish between text and binary data...

Re: [SQLObject] fetchAlternateID()

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

On Fri, 2003-04-18 at 15:44, Luke Opperman wrote:
> Not sure if i just saw a message about this, but can't find it..
> 
> modification to _SO_fetchAlternateID to deal with the situation where
> there is no record with that value.
> 
>     def _SO_fetchAlternateID(cls, dbIDName, value):
>         result = cls._connection._SO_selectOneAlt(
>             cls,
>             [cls._idName] +
>             [col.dbName for col in cls._columns],
>             dbIDName,
>             value)
>         if not result:
>             raise KeyError, "The object %s by the alternate ID (%s) %s
> does not exist" % (cls.__name__, dbIDName, value)
>         obj = cls(result[0])
>      ....

Sure, that seems right.  I've named it SQLObjectNotFound, subclass
LookupError.  At some point I'll get rid of the lazy fetching of column
data, at which point trying to instantiate a non-existant object will
raise the same exception.

  Ian

Re: [SQLObject] Patch for Postgres _fromDatabase support

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

Seems to work.  It's applied to CVS.

On Fri, 2003-04-18 at 07:44, David M. Cook wrote:
> Here's a first try at adding _fromDatabase support for the Postgres
> connection:
> 
> http://members.cox.net/davecook/pythonstuff/PG_fromDatabase.patch
> 
> One thing that makes me a little nervous is the use of eval to get the
> default from the string representation returned by Postgres.  I think it's
> safe in this context, but I'm still wary of eval.
> 
> I also added guessClass as a method to the class.  I left datetime in there
> for now.  Postgres doesn't have a datetime type AFAIK (but does have date
> and time).
> 
> Dave Cook
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

[SQLObject] TextCol

[Luke O. <lu...@me...>]

For those who like things more explicit, I was asked to create a
forced TextCol (instead of letting StringCol handle both cases).
Result:

class TextCol(StringCol):
    def __init__(self, *arg, **kw)
        #throw away possible keywords
        popKey(kw, 'length')
        popKey(kw, 'varchar')
        StringCol.__init__(self, *args, **kw)

Obviously it makes my life easier if it's checked in, but it's not too
important.

- Luke

--
 Many people are hamstrung by things like affection for
 fellow employees, honesty, desire to appear to be a
 "nice person," and other crippling limitations not
 suffered by the truly powerful and successful.

[SQLObject] fetchAlternateID()

[Luke O. <lu...@me...>]

Not sure if i just saw a message about this, but can't find it..

modification to _SO_fetchAlternateID to deal with the situation where
there is no record with that value.

    def _SO_fetchAlternateID(cls, dbIDName, value):
        result = cls._connection._SO_selectOneAlt(
            cls,
            [cls._idName] +
            [col.dbName for col in cls._columns],
            dbIDName,
            value)
        if not result:
            raise KeyError, "The object %s by the alternate ID (%s) %s
does not exist" % (cls.__name__, dbIDName, value)
        obj = cls(result[0])
     ....

Now, this raise the question of what error to raise. We're doing a
similar check in _init() if the ID is non-existent, and KeyError
isn't exactly the right error to throw for these "no such object
exists". We're catching a generic LookupError for now for both these
cases, but I suggesting an SQLObject-specific lookup error:

class SQLObjectLookupError(LookupError):
     pass

(or maybe named NoSuchObject(LookupError) ?)

just so that catches can be more explicit and not catch other generic
Key/Lookup Errors. Thoughts? (Think of a better name for it? I
definitely think it should inherit from LookupError, and not just
Exception..)

- Luke

[SQLObject] Patch for Postgres _fromDatabase support

[David M. C. <da...@da...>]

Here's a first try at adding _fromDatabase support for the Postgres
connection:

http://members.cox.net/davecook/pythonstuff/PG_fromDatabase.patch

One thing that makes me a little nervous is the use of eval to get the
default from the string representation returned by Postgres.  I think it's
safe in this context, but I'm still wary of eval.

I also added guessClass as a method to the class.  I left datetime in there
for now.  Postgres doesn't have a datetime type AFAIK (but does have date
and time).

Dave Cook

Re: [SQLObject] _fromDatabase for Postgres

[David M. C. <da...@da...>]

On Fri, Apr 18, 2003 at 01:37:58AM -0700, David M. Cook wrote:

> For the curious, here's a query (found using psql -E) that gets the same
> info as the MySQL "SHOW COLUMNS FROM %s" query (field, type, notnull,
> default):
> 
> SELECT a.attname, pg_catalog.format_type(a.atttypid, a.atttypmod),
> a.attnotnull, substring(d.adsrc for 128)
> FROM pg_catalog.pg_attribute a, pg_catalog.pg_attrdef d
> WHERE a.attrelid = '%s'::regclass AND d.adrelid=a.attrelid
> AND d.adnum = a.attnum AND a.attnum > 0 AND NOT a.attisdropped
> ORDER BY a.attnum

Erk, that won't work.  This will

SELECT a.attname, pg_catalog.format_type(a.atttypid, a.atttypmod),
       a.attnotnull, 
       (SELECT substring(d.adsrc for 128) FROM pg_catalog.pg_attrdef d 
        WHERE d.adrelid=a.attrelid AND d.adnum = a.attnum)
FROM pg_catalog.pg_attribute a 
WHERE a.attrelid ='%s'::regclass
      AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum

Dave

Re: [SQLObject] _fromDatabase for Postgres

[David M. C. <da...@da...>]

On Fri, Apr 18, 2003 at 01:37:58AM -0700, David M. Cook wrote:

> FOREIGN KEY (recording_id) REFERENCES recording(id) ON UPDATE NO ACTION ON
> DELETE CASCADE
 
Left out a crucial word:

This can be *parsed* with the regular expression:
 
\((.+)\) REFERENCES (.+)\(

Dave