sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] UnicodeCol bug

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

>>    return value.encode(self.db_encoding)
>>AttributeError: 'NoneType' object has no attribute 'encode'
> 
> 
>    Fixed in revision 476.
>

Thanks.

Kinda nice to have project maintainers in different time zones. Your bug 
report gets noticed and fixed at any time of the day. ;-)

Re: [SQLObject] Releases and versioning.

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

Carlos Ribeiro wrote:

>>   Then use the latest checkout from the trunk. I think it is in a more
>>or less stable state (now). Run tests. This is the best you can get now.
> 
> 
> Having tags to mark intermediate releases would be helpful -- it would
> encourage the habit of creating mini-releases more frequently (0.6.1,
> 0.6.2...). But reorganizing the repository may be a little bit
> difficult at this point -- lots of people already have copies pointing
> to the current structure. But it can be done, anyway, if there's
> enough perceived advantage in doing it. (I think it does :-)

+1 on this. ;-)

Re: [SQLObject] UnicodeCol bug

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

On Fri, Dec 10, 2004 at 02:58:31PM +0200, Max Ischenko wrote:
>     return value.encode(self.db_encoding)
> AttributeError: 'NoneType' object has no attribute 'encode'

   Fixed in revision 476.

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

Re: [SQLObject] Releases and versioning.

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

On Fri, 10 Dec 2004 16:09:00 +0300, Oleg Broytmann <ph...@ma...> wrote:
> On Fri, Dec 10, 2004 at 11:39:25AM +0000, Alan Kennedy wrote:
> > AFAIK, svn
> > treats tags and branches identically.
> 
>    Subversion, actually, does not have a builtin notion of tags and
> branches. Svn operates on trees. But one can name theese trees. The
> names are just URIs, so one can name them in whatever way one prefers.
> "Tags" and "branches" are just two examples of the naming.

The SVN book actually makes this point clear, but nevertheless,  it
strongly suggests the use of the trunk/branches/tags structure. That's
what I have used for my own SVN repository. It did sound strange at
first, but as the project grows it does make a lot of sense.
 
>    Then use the latest checkout from the trunk. I think it is in a more
> or less stable state (now). Run tests. This is the best you can get now.

Having tags to mark intermediate releases would be helpful -- it would
encourage the habit of creating mini-releases more frequently (0.6.1,
0.6.2...). But reorganizing the repository may be a little bit
difficult at this point -- lots of people already have copies pointing
to the current structure. But it can be done, anyway, if there's
enough perceived advantage in doing it. (I think it does :-)

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

Re: [SQLObject] UnicodeCol bug

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

Ian Bicking wrote:
> I was going to add a FAQ entry about unicode, but then it had a bunch of 
> code, and I figured I should just include the code.  Now there is a 
> UnicodeCol, mostly the same as what Oleg described before.

The implementation contains a bug: it doesn't handle None property, when 
you try to read or set a NULL value:

   File "D:\Python23\Lib\site-packages\sqlobject\main.py", line 890, in 
__init__
     self._create(id, **kw)
   File "D:\Python23\Lib\site-packages\sqlobject\main.py", line 920, in 
_create
     self.set(**kw)
   File "D:\Python23\Lib\site-packages\sqlobject\main.py", line 774, in set
     kw[name] = dbValue = fromPython(value, self._SO_validatorState)
   File "D:\Python23\Lib\site-packages\sqlobject\col.py", line 347, in 
fromPython
     return value.encode(self.db_encoding)
AttributeError: 'NoneType' object has no attribute 'encode'

Re: [SQLObject] Releases and versioning.

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

On Fri, Dec 10, 2004 at 11:39:25AM +0000, Alan Kennedy wrote:
> AFAIK, svn 
> treats tags and branches identically.

   Subversion, actually, does not have a builtin notion of tags and
branches. Svn operates on trees. But one can name theese trees. The
names are just URIs, so one can name them in whatever way one prefers.
"Tags" and "branches" are just two examples of the naming.

> Might it be better to stick with perceived terminology, i.e. use tags to 
> label releases? And reserve branches for parallel development, e.g. 
> experimental code bases such as the "inheritance" branch?

   Probably. Ian has not created a strict policy on that beside the
http://svn.colorstudy.com/using-this-repository.txt .

> Hmm, so where can I find/download the 0.6.1 release? Was there a formal 
> release of 0.6.1?

   There was no.

> > Then use 0.5.3.
> 
> If it wasn't for the incompatible API between 0.5 and 0.6, I'd consider it.

   Then use the latest checkout from the trunk. I think it is in a more
or less stable state (now). Run tests. This is the best you can get now.

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

Re: [SQLObject] Releases and versioning.

[Alan K. <sql...@xh...>]

Oleg,

Thanks for the informative reply.

[Alan Kennedy]
 >>But I see that the tagging is not used in that repository.

[Oleg Broytmann]
 > We do not tag SQLObject releases.

That's a pity. Tags are such an elegant and clean way to manage releases.

It appears to me that the use of "branches" in the ColorStudy svn repo 
is the same usage as I would expect "tags" to be used for. AFAIK, svn 
treats tags and branches identically. So the ColorStudy repo is using 
"branches" for the purpose that "tags" were intended. I know that 
branches and tags are the same thing under svn (i.e. cheap copies), but 
they are different in people's minds. People expect "branches" to 
contain parallel development code bases, and expect "tags" to contain 
fixed snapshots of a code base.

Might it be better to stick with perceived terminology, i.e. use tags to 
label releases? And reserve branches for parallel development, e.g. 
experimental code bases such as the "inheritance" branch?

[Alan Kennedy]
 >>Then I tried
 >>
 >>prompt>svn ls svn://colorstudy.com/branches/SQLObject/
 >>
 >>Which got the following list
 >>
 >>0.5/
 >>0.6/
 >>
 >>I'm presuming that the latter contains the 0.6 code.
 >>
 >>But which release? 0.6.0? 0.6.1? Or the head revision? It's confusing,
 >>without going through the checkin logs in detail to see which version
 >>is which.

[Oleg Broytmann]
 > 0.6.0. The "head" is in the trunk.

Hmm, so where can I find/download the 0.6.1 release? Was there a formal 
release of 0.6.1? My understanding is that the current HEAD contains 
0.6.1+, i.e. whatever comprised the 0.6.1 release *plus* whatever 
changes/fixes have been made since, and which will eventually become 0.6.2.

[Alan Kennedy]
 >>I like to use fixed versions of software, rather than the "bleeding
 >>edge", straight form the repository: it makes testing, installation
 >>and environment management *so* much easier.

[Oleg Broytmann]
 > Then use 0.5.3. It is much more "fixed" than any other. Ian and I
 > fixed a lot of bugs in the trunk in the would-be 0.6.2, but until
 > 0.6.2 will really be released consider 0.6 as a development version.

If it wasn't for the incompatible API between 0.5 and 0.6, I'd consider it.

Thanks and regards,

Alan.

Re: [SQLObject] Releases and versioning.

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

On Thu, Dec 09, 2004 at 10:15:42PM +0000, Alan Kennedy wrote:
> uncertain as to whether "SQLObject-0.6-1.noarch.rpm" contains 0.6.0 or 
> 0.6.1?)

   0.6.0.

> So I thought I'd go to the definitive source, the ColorStudy svn 
> repository. First, I tried to see if there were any svn tags set
> 
> prompt> svn ls svn://colorstudy.com/tags/SQLObject/
> svn: URL non-existent in that revision
> 
> But I see that the tagging is not used in that repository.

   We do not tag SQLObject releases.

> Then I tried
> 
> prompt>svn ls svn://colorstudy.com/branches/SQLObject/
> 
> Which got the following list
> 
> 0.5/
> 0.6/
> 
> I'm presuming that the latter contains the 0.6 code.
> 
> But which release? 0.6.0? 0.6.1? Or the head revision? It's confusing, 
> without going through the checkin logs in detail to see which version is 
> which.

   0.6.0. The "head" is in the trunk.

> Am I the only one who finds this confusing?

   Let's me increase the confusion a bit. There are also branches not
under the "branches/" URL! :)
   Now let's me decrease the confusion a bit. You can browse the entire
repository on the web: http://svn.colorstudy.com/ . There you can find
all software in the repository (not only SQLObject), and all branches.
Do not miss my inheritance branch at
   http://svn.colorstudy.com/home/phd/SQLObject/inheritance/ .

> I like to use fixed versions of software, rather than the "bleeding 
> edge", straight form the repository: it makes testing, installation and 
> environment management *so* much easier.

   Then use 0.5.3. It is much more "fixed" than any other. Ian and I
fixed a lot of bugs in the trunk in the would-be 0.6.2, but until 0.6.2
will really be released consider 0.6 as a development version.

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

[SQLObject] Releases and versioning.

[Alan K. <sql...@xh...>]

Hi all,

I'm seeking some clarity on the versioning and release mechanism for 
SQLObject.

On visiting the sqlobject.org site, various parts of the site refer to 
the current version as 0.5.2. I.e. the front page has a list of "recent 
releases", in which 0.5.2 is the most recent.

But I know that 0.6 is available, because I checked it out of svn myself 
:-) Or did I?

I thought that 0.6 was the latest version, but on looking at the News 
page on the site, that lists 0.6.1 as the most recent release.

http://www.sqlobject.org/docs/News.html

Also, the SQLObject documentation page is the one for 0.6.1.

http://sqlobject.org/docs/SQLObject.html

But I can't see anywhere on the site or on sourceforge to actually 
download 0.6.1. The most recent release on sourceforge is 0.6.0. (I'm 
uncertain as to whether "SQLObject-0.6-1.noarch.rpm" contains 0.6.0 or 
0.6.1?)

http://sourceforge.net/project/showfiles.php?group_id=74338

So I thought I'd go to the definitive source, the ColorStudy svn 
repository. First, I tried to see if there were any svn tags set

prompt> svn ls svn://colorstudy.com/tags/SQLObject/
svn: URL non-existent in that revision

But I see that the tagging is not used in that repository.

Then I tried

prompt>svn ls svn://colorstudy.com/branches/SQLObject/

Which got the following list

0.5/
0.6/

I'm presuming that the latter contains the 0.6 code.

But which release? 0.6.0? 0.6.1? Or the head revision? It's confusing, 
without going through the checkin logs in detail to see which version is 
which.

Am I the only one who finds this confusing?

Lastly, I have a suggestion to make: use svn tagging to tag/label a 
release so that it is easy to retrieve.

For example, if the 0.6.1 release had been tagged, then I could check 
out the 0.6.1 release with a command like

svn co svn://colorstudy.com/tags/SQLObject/RELEASE_0_6_1

Or something like that. SVN tagging is a simple and powerful mechanism 
to manage this sort of issue (I think RCS and CVS call it "labelling").

I like to use fixed versions of software, rather than the "bleeding 
edge", straight form the repository: it makes testing, installation and 
environment management *so* much easier.

Regards,

Alan.

Re: [SQLObject] Defer creating/updating objects in the database

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

Peter Butler wrote:
> I'm just getting to grips with SQLObject so please pardon me if this
> is a question that has been asked before.
> 
> Is it possible to defer the insert/update so that the object can be
> validated before the changes are written to the database?
> 
> I would like to be able to do the following:
> 
> object = MyObject() 
 > object.field1 = someValue
 > object.field2 = someValue
 > object.validate() object.save()
> 
> With similar logic for objects that already exist in the database.
> 
> From looking through the tutorial and source the philosophy seems
> to be to write all object changes to the database as they occur.
> This makes sense to me as it simplifies everything.

You can also set several keys at once using .set(); you might require 
that the object be valid for each call to .set().  You can also delay 
saves to the database with _lazyUpdate = True, then you can override the 
.syncUpdate() method to do validation.  Hmm... apparently I haven't 
included lazyUpdate in the docs, but it is noted in the News.

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

[SQLObject] Re: DBMConnection

[Kevin D. <kda...@ya...>]

Ian Bicking wrote:
>...
> have a properly-formatted dbm file laying around.  CSV or XML files 
> would be more interesting.  It'll be difficult if the format is 
> extensible (like mbox, with extensible headers), or hierarchical
(like 
> many XML uses), but there's probably a class of cases where it is 
> useful 
>even for those formats.

XMLObject is a package that borrows your ideas from SQLObject (and some
code I think) to provide a XML persistence layer.  It works very well
for simple cases, but has issues when dealing with inheritance.

The XML-enabled sublcasses are created just like SQLObject subclasses. 
Then there are 'toXml' and 'fromXml' methods that do what is expected.

=====
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Dahlhausen          'Do' or 'do not.' There is no 'Try.' 
 http://members.nccw.net/kdahlhaus/              -Yoda

RE: [SQLObject] Defer creating/updating objects in the database

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

I am using SQLObject with a pre-existing Postgresql database, so I enforce
all validation constraints there instead of in the object mapper. I think
that's really the most appropriate place to do data validation. Your
situation may dictate otherwise, though.


>Is it possible to defer the insert/update so that the object can be
validated 
>before the changes are written to the database?

[SQLObject] Defer creating/updating objects in the database

[Peter B. <pet...@14...>]

I'm just getting to grips with SQLObject so please pardon me if this is a question that has been asked before.

Is it possible to defer the insert/update so that the object can be validated before the changes are written to the database?

I would like to be able to do the following:

object = MyObject()
object.field1 = someValue
object.field2 = someValue
object.validate()
object.save()

With similar logic for objects that already exist in the database.

>From looking through the tutorial and source the philosophy seems to be to write all object changes to the database as they occur.  This makes sense to me as it simplifies everything.

With this in mind I tried to create a wrapper class that collects updates and applies them to the object all at once, something like this:

class FormValues:
    def __init__(self, clazz = None, object = None):
        #clazz is set if we should create a new object, object is set if it's a pre-existing object
        self.__clazz = clazz
        self.__object = object

    def __getattr__(self, attr):
        if self.__dict__.has_key(attr):
            return self.__dict__[attr]
        else:
            return None

    def save(self):
        if self.__object is None:
            self.__object = self.__clazz()
        for key in self.__dict__.keys():
            if self.__object.__dict__.has_key(key):
                self.__object.__dict__[key] = self.__dict__.[key]

The problem with this is that I'm not able to create the new object, because the self.__clazz() call requires keyword arguments for each field.  I can get this to work by setting defaults for each column, but this seems an odd way to go about things and doesn't work very well for relations (and for tables with no auto increment field the ID is always 0, which causes a duplicate record error).  Is there another way to create a new object?

I've also tried creating the object as follows:
	self.__object = self.__clazz(_SO_fetch_no_create=1)

Which works initially but falls over as soon as it tries to write anything to the database because the object hasn't been initialised properly.

Am I going about this the wrong way?  Is there a better way to acheive this?

Any comments would be greatly appreciated.

Peter Butler

Re: [SQLObject] dbm connection

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

Oleg Broytmann wrote:
> On Tue, Dec 07, 2004 at 10:32:37AM -0600, Ian Bicking wrote:
> 
>>Yes, we can just get rid of it.  I had moved it aside when I separated 
>>db backends into separate packages, but I hadn't tested it since -- he. 
> 
> 
>    Removed at revision 463.
> 
> 
>>and there's other better embedded databases.
> 
> 
>    In context of SQLObject - SQLite, of course. I don't have a word
> against BerkeleyDB or GNU dbm, but in context of SQLObject I'd like to
> recommend to use an established SQL environemnt for bsddb - MySQL!
>    Somewhere in a distant future I'd like to think about making
> SQLObject-like API for non-SQL based stores (dbm, xml, csv), but they
> should be implemented at much higher level - something like DBMObject
> and XMLObject, not at the connection level.

DBMConnection does something along these lines.  I'd played with a 
couple other backends, including flat files.  A CSV backend would 
certainly be possible.

SQLBuilder includes the ability to bind its free variables and evaluate 
the expression (which is what DBMConnection did).  This way you can use 
SQL-like queries without any SQL engine.  Typically implemented with a 
linear search for every query, it's a little slow, but maybe workable 
for some use cases.  Once you start adding indexing and query 
optimization, it starts making sense to think about simply moving it 
into a real database.

I think dbm wasn't very interesting, because no one would ever happen to 
have a properly-formatted dbm file laying around.  CSV or XML files 
would be more interesting.  It'll be difficult if the format is 
extensible (like mbox, with extensible headers), or hierarchical (like 
many XML uses), but there's probably a class of cases where it is useful 
even for those formats.

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

Re: [SQLObject] dbm connection

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

On Tue, Dec 07, 2004 at 10:32:37AM -0600, Ian Bicking wrote:
> Yes, we can just get rid of it.  I had moved it aside when I separated 
> db backends into separate packages, but I hadn't tested it since -- he. 

   Removed at revision 463.

> and there's other better embedded databases.

   In context of SQLObject - SQLite, of course. I don't have a word
against BerkeleyDB or GNU dbm, but in context of SQLObject I'd like to
recommend to use an established SQL environemnt for bsddb - MySQL!
   Somewhere in a distant future I'd like to think about making
SQLObject-like API for non-SQL based stores (dbm, xml, csv), but they
should be implemented at much higher level - something like DBMObject
and XMLObject, not at the connection level.

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

[SQLObject] UnicodeCol

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

I was going to add a FAQ entry about unicode, but then it had a bunch of 
code, and I figured I should just include the code.  Now there is a 
UnicodeCol, mostly the same as what Oleg described before.

This doesn't solve the query issue, since queries involving unicode will 
fail currently.  There's a couple ways to do that:
   * Process-global encodings, added to sqlobject.converters
   * If we move to database parameters instead of building SQL textually,
     we could do per-database default encodings.  The dbconnection
     instance would loop through the parameters and convert any unicode
     strings it found.
   * sqlbuilder.SQLObjectField could pay attention to encoding.
     Actually, I want to get rid of the .q stuff, and just make
     cls.column into a descriptor, so that when fetched from a class it's
     an object that can be used in a query.  But either way this is
     fairly doable.

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

Re: [SQLObject] dbm connection

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

Oleg Broytmann wrote:
>    How long ago people stopped to use dbm connections? The dbmconnection
> module seems to be broken beyond repair - the module forgets to import
> required modules (os, atexit), expects wrong parameters in methods, does
> all sorts of wrongdoing. I tried to fix it, but completely failed.
>    I'd like to drop it altogether. Especially in the light of work I am
> doing with SQL queries (DB API paramstyle parameters) - there is no a
> paramstyle for dbm cursors, there is no such thing as "dbm cursor". To
> make it work with SQL queries and parameters it need to be heaviliy
> modified after it would have been repaired... if it is possible at all.
>    Or should I try to repair it? Or ignore it for now?

Yes, we can just get rid of it.  I had moved it aside when I separated 
db backends into separate packages, but I hadn't tested it since -- he. 
  It shouldn't be too far from working, but it was just an experiment 
and there's other better embedded databases.

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

[SQLObject] dbm connection

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

Hello!

   How long ago people stopped to use dbm connections? The dbmconnection
module seems to be broken beyond repair - the module forgets to import
required modules (os, atexit), expects wrong parameters in methods, does
all sorts of wrongdoing. I tried to fix it, but completely failed.
   I'd like to drop it altogether. Especially in the light of work I am
doing with SQL queries (DB API paramstyle parameters) - there is no a
paramstyle for dbm cursors, there is no such thing as "dbm cursor". To
make it work with SQL queries and parameters it need to be heaviliy
modified after it would have been repaired... if it is possible at all.
   Or should I try to repair it? Or ignore it for now?

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

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

On Mon, 06 Dec 2004 15:48:09 -0600, Ian Bicking <ia...@co...> wrote:
> Carlos Ribeiro wrote:
> The lines don't match up with the current checkout, but the only place I
> see that line is for DecimalCol, not StringCol.

Sorry, really sorry. A messup of mine. My module referred another
module, and I traced the assert failure to the wrong one. Coincidently
enough, I had just removed the size for some StringCol's... and it
matched exactly that location on another file. An enourmous
coincidence.

-- 
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, 06 Dec 2004 11:06:33 -0600, Ian Bicking <ia...@co...> wrote:
> 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.

If I only could find a way to do it in SQLObject without having to
resort to database driver patching, that would be perfect :-) But
unfortunately, things are not that easy, unless I store all my money
values in text columns - but then I'll lose big on SQL aggregation
functions & stuff like that. But I'm really tempted to do it, just to
avoid messing with db drivers for now.

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

Re: [SQLObject] Postgres tableExists

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

On Mon, Dec 06, 2004 at 04:28:09PM -0600, Ian Bicking wrote:
> >>The "'%s'" % tableName is bad, though.
> >
> >   That's easy to fix, and I'll fix it. What is more interesting - what

   Committed at version 450.

> >does correspond to pg_class in Postgres >= 7.3? Still pg_class? or
> >something in pg_catalog? Does anybody know newer postgres catalogs?
> 
> pg_class and pg_catalog.pg_class seem to be the same thing in PG 7.4. 
> Actually, maybe all pg_catalog schema references are unnecessary in PG 
> 7.4?  I wonder if that's a transitional thing, e.g., in PG 8.0 you'll 
> have to use the schema name, but until then it's optional?

   I suspect so.

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

Re: [SQLObject] Postgres tableExists

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

Oleg Broytmann wrote:
> On Mon, Dec 06, 2004 at 04:12:04PM -0600, Ian Bicking wrote:
> 
>>Oleg Broytmann wrote:
>>
>>>What is so obviously broken here? Looks pretty good for me.
>>>
>>>   def tableExists(self, tableName):
>>>       # @@: obviously broken
>>>       result = self.queryOne("SELECT COUNT(relname) FROM pg_class WHERE 
>>>       relname = '%s'"
>>>                              % tableName)
>>>       return result[0]
>>
>>I don't think I put that comment in there; I didn't originally write the 
>>Postgres code.
> 
> 
>    I didn't blame anyone :), I just asked - my be I've overlooked
> something important.

I was just saying I don't know the original intention of the comment.

>>The "'%s'" % tableName is bad, though.
> 
> 
>    That's easy to fix, and I'll fix it. What is more interesting - what
> does correspond to pg_class in Postgres >= 7.3? Still pg_class? or
> something in pg_catalog? Does anybody know newer postgres catalogs?

pg_class and pg_catalog.pg_class seem to be the same thing in PG 7.4. 
Actually, maybe all pg_catalog schema references are unnecessary in PG 
7.4?  I wonder if that's a transitional thing, e.g., in PG 8.0 you'll 
have to use the schema name, but until then it's optional?

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

Re: [SQLObject] Postgres tableExists

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

On Mon, Dec 06, 2004 at 04:12:04PM -0600, Ian Bicking wrote:
> Oleg Broytmann wrote:
> >What is so obviously broken here? Looks pretty good for me.
> >
> >    def tableExists(self, tableName):
> >        # @@: obviously broken
> >        result = self.queryOne("SELECT COUNT(relname) FROM pg_class WHERE 
> >        relname = '%s'"
> >                               % tableName)
> >        return result[0]
> 
> I don't think I put that comment in there; I didn't originally write the 
> Postgres code.

   I didn't blame anyone :), I just asked - my be I've overlooked
something important.

> The "'%s'" % tableName is bad, though.

   That's easy to fix, and I'll fix it. What is more interesting - what
does correspond to pg_class in Postgres >= 7.3? Still pg_class? or
something in pg_catalog? Does anybody know newer postgres catalogs?

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

Re: [SQLObject] Postgres tableExists

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

Oleg Broytmann wrote:
> What is so obviously broken here? Looks pretty good for me.
> 
>     def tableExists(self, tableName):
>         # @@: obviously broken
>         result = self.queryOne("SELECT COUNT(relname) FROM pg_class WHERE relname = '%s'"
>                                % tableName)
>         return result[0]

I don't think I put that comment in there; I didn't originally write the 
Postgres code.  The "'%s'" % tableName is bad, though.

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

[SQLObject] Postgres tableExists

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

What is so obviously broken here? Looks pretty good for me.

    def tableExists(self, tableName):
        # @@: obviously broken
        result = self.queryOne("SELECT COUNT(relname) FROM pg_class WHERE relname = '%s'"
                               % tableName)
        return result[0]

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