sqlobject-discuss — All things SQLObject-related

[SQLObject] SQLObject is alive!

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

Hello! I am going to do the next round of minor releases. Does anybody need
a beta period?

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

Re: [SQLObject] SQLObject and Pylons 0.9.7

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

On Wed, Apr 22, 2009 at 01:36:52PM +0200, Lutz Steinborn wrote:
> Pylons has changed to SQLAlchemy as the preferred ORM. Can anybody tell me how
> to use SQLObject with pylons 0.9.7 ?

   Did this stop working?
http://wiki.pylonshq.com/display/pylonscookbook/LEGACY+DOCUMENT+How+to+write+a+basic+blog+with+Pylons+and+SQLObject

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

[SQLObject] SQLObject and Pylons 0.9.7

[Lutz S. <l.s...@4c...>]

Hi,

Pylons has changed to SQLAlchemy as the preferred ORM. Can anybody tell me how
to use SQLObject with pylons 0.9.7 ?
I can't find any information about this issue in the pylons mailinglists. I
like SQLObject and don't see any reason to change to SA.

Kindly regards

-- 
Lutz Steinborn
4c Business Service GmbH
Putzbrunner Str. 71
81739 Muenchen

Fon: +49 89 99341 30, Fax +49 89 99341 399
l.s...@4c..., http://www.4c-shopping.de

---------------------------------------------------------
Sitz der Gesellschaft: Putzbrunner Str. 71, 81739 Muenchen
Vertretungsberechtigter Geschaeftsfuehrer: Frank W. Lutze
Registergericht: Amtsgericht Muenchen
Registernummer: HR 130 207
Ustnr. gemaess § 27 a Umsatzsteuergesetz: DE 206 864 106

Re: [SQLObject] Is this a bug?

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

On Mon, Apr 13, 2009 at 09:51:47AM +0200, Iwan Vosloo wrote:
> On Wed, 2009-04-08 at 00:40 +0400, Oleg Broytmann wrote:
> > On Mon, Mar 30, 2009 at 04:16:16PM +0200, Iwan Vosloo wrote:
> > > This looks like a bug - correct me if I'm wrong.  Transaction.close()
> > > does not close the underlying connection. Seems like the __getattr__ of
> > > Transaction is to blame if I understand correctly.
> > 
> >    I think .close() on a Transaction must be forbidden. I am going to add a
> > .close() method to Transaction that raises an exception saying "Do not call
> > close() - call either commit(), commit(close=True) or rollback()". Ok?
> 
> Sounds good to me Oleg.  
> 
> Only thing is that if one is familiar with the DBAPI, one intuitively
> expects a sqlobject Transaction so work like a DBAPI Connection (or is
> it just me?).  If so, you sortof expect it to have .commit and .close
> methods.
> 
> But having it complain with a nice error message like that make the
> difference with the DBAPI explicit.  Which is also good.

   Calling .close() on a transaction instance means the user has messed up
connections and transaction instances so I decided the exception is
TypeError. Revisions 3856-3858. Thank you!

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

Re: [SQLObject] Bug? Spurious connection to postgresql

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

On Mon, Apr 13, 2009 at 09:28:36AM +0200, Iwan Vosloo wrote:
> On Wed, 2009-04-08 at 00:37 +0400, Oleg Broytmann wrote:
> >    The problem with .server_version is that it's a property, so it is
> > called at the very beginning of said __getattr__ and 'self' is the
> > Connection, not the Transaction so server_version calls wrong
> > self.queryOne(). I think, the simplest way to fix this would be to make the
> > property a normal method. Then __getattr__ will wrap self and the
> > .server_version() method will call .queryOne() on the Transaction, not
> > Connection.
> >    This is an API change but I think it's a small evil 'cause it is a
> > change in an API that is hardly used by many.
> >    What do you think?
> 
> Sounds good to me.  Even we do not really use server_version directly -
> it is just being called as a side effect of doing other things.

   Fixed in the revisions 3853-3855 (branches 0.9, 0.10 and the trunk).
Thank you!

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

Re: [SQLObject] Is this a bug?

[Iwan V. <iw...@re...>]

On Wed, 2009-04-08 at 00:40 +0400, Oleg Broytmann wrote:
> On Mon, Mar 30, 2009 at 04:16:16PM +0200, Iwan Vosloo wrote:
> > This looks like a bug - correct me if I'm wrong.  Transaction.close()
> > does not close the underlying connection. Seems like the __getattr__ of
> > Transaction is to blame if I understand correctly.
> 
>    I think .close() on a Transaction must be forbidden. I am going to add a
> .close() method to Transaction that raises an exception saying "Do not call
> close() - call either commit(), commit(close=True) or rollback()". Ok?

Sounds good to me Oleg.  

Only thing is that if one is familiar with the DBAPI, one intuitively
expects a sqlobject Transaction so work like a DBAPI Connection (or is
it just me?).  If so, you sortof expect it to have .commit and .close
methods.

But having it complain with a nice error message like that make the
difference with the DBAPI explicit.  Which is also good.

Thanks
-i

Re: [SQLObject] col.title (was: ForeignKey)

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

On Fri, Apr 10, 2009 at 08:14:48PM +0200, Markus W. Barth wrote:
> I have found the (afaik undocumented) keyword param "title" of the col 
> constructor. Is this meant as some sort of display name? In other words, can 
> I set this and retrieve its value later for displaying it as a label?

   Yes. It's currently unused.

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

Re: [SQLObject] ForeignKey

[Markus W. B. <ma...@si...>]

thanks for your help. Another question:

I have found the (afaik undocumented) keyword param "title" of the col 
constructor. Is this meant as some sort of display name? In other words, can 
I set this and retrieve its value later for displaying it as a label?

On Friday 10 April 2009 14:25:32 Oleg Broytmann wrote:
> On Fri, Apr 10, 2009 at 12:06:38PM +0200, Markus W. Barth wrote:
> > Hi,
> > is there a possibility to figure out at runtime wich table a ForeignKey
> > refers to?
>
> from sqlobject.classregistry import findClass
>
> class Test1(SQLObject):
>     test1=MultipleJoin('Test2', joinColumn='post_id')
>
> class Test2(SQLObject):
>     test2=ForeignKey('Test1')
>
> print findClass(Test2.sqlmeta.columns['test2ID'].foreignKey,
> Test2.sqlmeta.registry)
>
> Oleg.

Re: [SQLObject] ForeignKey

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

On Fri, Apr 10, 2009 at 12:06:38PM +0200, Markus W. Barth wrote:
> Hi,
> is there a possibility to figure out at runtime wich table a ForeignKey refers 
> to?

from sqlobject.classregistry import findClass

class Test1(SQLObject):
    test1=MultipleJoin('Test2', joinColumn='post_id')

class Test2(SQLObject):
    test2=ForeignKey('Test1')

print findClass(Test2.sqlmeta.columns['test2ID'].foreignKey, Test2.sqlmeta.registry)

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

[SQLObject] ForeignKey

[Markus W. B. <ma...@si...>]

Hi,
is there a possibility to figure out at runtime wich table a ForeignKey refers 
to?

Re: [SQLObject] A problem about "ForeignKey", help!!

[Hanjie <luc...@gm...>]

Great!!!
eventually, i find the problem!!!!
ForeignKey should use the same name with the related table.
How simple it is, but I waste a whole day on it!


Worry: post=ForeignKey('postTable')
correct: postTable=ForeignKey('postTable')


On Fri, Apr 10, 2009 at 1:17 AM, Oleg Broytmann <ph...@ph...> wrote:

> On Thu, Apr 09, 2009 at 11:44:52PM +0200, Hanjie wrote:
> > class postTable(SQLObject):
> >     title = UnicodeCol(length=50)
> >     content = UnicodeCol()
> >     comments=MultipleJoin('commentTable')
> >
> > class commentTable(SQLObject):
> >     post=ForeignKey('postTable')
> >     authorName=UnicodeCol(length=255,notNull=False)
> >     content=UnicodeCol()
> >
> > But, when I want to use q.comment, the error arise:
> > OperationalError: Unknown column 'post_table_id' in 'where clause'
>
>    The problem lies here:
>
> class postTable(SQLObject):
>     comments=MultipleJoin('commentTable')
>
> class commentTable(SQLObject):
>    post=ForeignKey('postTable')
>
>    There are simply too many different names: 'comments', 'commentTable',
> 'post' and 'postTable'. Multitude of these names confuses SQLObject so it
> doesn't know how to count comments of a post. One can help SQLObject by
> explicitly naming the column in the other table:
>
> class postTable(SQLObject):
>    comments=MultipleJoin('commentTable', joinColumn='post_id')
>
> Oleg.
> --
>     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
>           Programmers don't die, they just GOSUB without RETURN.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

Re: [SQLObject] A problem about "ForeignKey", help!!

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

On Thu, Apr 09, 2009 at 11:44:52PM +0200, Hanjie wrote:
> class postTable(SQLObject):
>     title = UnicodeCol(length=50)
>     content = UnicodeCol()
>     comments=MultipleJoin('commentTable')
> 
> class commentTable(SQLObject):
>     post=ForeignKey('postTable')
>     authorName=UnicodeCol(length=255,notNull=False)
>     content=UnicodeCol()
> 
> But, when I want to use q.comment, the error arise:
> OperationalError: Unknown column 'post_table_id' in 'where clause'

   The problem lies here:

class postTable(SQLObject):
    comments=MultipleJoin('commentTable')

class commentTable(SQLObject):
    post=ForeignKey('postTable')

   There are simply too many different names: 'comments', 'commentTable',
'post' and 'postTable'. Multitude of these names confuses SQLObject so it
doesn't know how to count comments of a post. One can help SQLObject by
explicitly naming the column in the other table:

class postTable(SQLObject):
    comments=MultipleJoin('commentTable', joinColumn='post_id')

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

[SQLObject] A problem about "ForeignKey", help!!

[Hanjie <luc...@gm...>]

Hi any man:
please help me, I have been confused by this problem for whole day.

I have two table and I want to use a foreignKey connect then together.

My coding is following:


class postTable(SQLObject):
    title = UnicodeCol(length=50)
    content = UnicodeCol()
    comments=MultipleJoin('commentTable')

class commentTable(SQLObject):
    post=ForeignKey('postTable')
    authorName=UnicodeCol(length=255,notNull=False)
    content=UnicodeCol()


Then I input "describe table post_table"
find the structure of post_table only content : id, title,content.
I can use like q.id, q.title, q.content.
But, when I want to use q.comment, the error arise:

I waste a whole day on this issue, please help me, I really need to use
q.comment.
how to solve it.
Thank you in advance


My problem detail(I am studying how to use turbogears):

---------------------------model.py---------------------------------
class postTable(SQLObject):
    title = UnicodeCol(length=50)
    content = UnicodeCol()
    postDate = DateTimeCol(default=datetime.now())
    isPublished= BoolCol(default=False)
    comments=MultipleJoin('commentTable')
    def _get_html_content(self):
        return publish_parts(self.content,
                writer_name="html")["html_body"]
    html_content=property(_get_html_content)

class commentTable(SQLObject):
    post=ForeignKey('postTable')
    authorName=UnicodeCol(length=255,notNull=False)
    authorEmail=StringCol(length=255,notNull=False)
    authorUrl=StringCol(length=255,notNull=False)
    commentDate=DateTimeCol(default=datetime.now())
    content=UnicodeCol()


------------------------------control.py-------------------------------------------

class Root(controllers.RootController):
    @expose(template="assignment.templates.welcome")
    def index(self):
        posts = assignment.model.postTable.select()
        return dict(posts=posts)

    @expose(template="assignment.templates.post")
    def post(self,id):
        p=assignment.model.postTable.get(int(id))
        return dict(post=p)


----------------------------------welcome.kid----------------------------------------
<body>
    <div id = "posts">
        <div py:for="post in posts" id="post_${post.id}">
            <h2 py:content="post.title">Post title here</h2>
            <div class="postmeta">
                Posted on
                <span class="postdate"
py:content="post.postDate">01/01/01</span>
            </div>
            <div class="content" py:content="XML(post.html_content)">
                This is where your post's content is displayed.
            </div>
            <div class="comments">
                <div py:for="comment in post.comments" id="comment_${
comment.id}"> ##problem should be here
                    <div class="commentmeta">
                        Comment by
                        <span py:if="comment.authorUrl" py:strip=''>
                            <a href="${comment.authorUrl}"
py:content="comment.authorName">Author with link</a>
                        </span>
                        <span py:if="not comment.authorUrl" py:strip=''
py:content="comment.authorName">
                            Author without link
                        </span>
                        on
                        <span
py:content="comment.commentDate">01/01/01</span>
                    </div>
                </div>
            </div>
                    <div class="content" py:content="comment.content">
                            Comment content here.
                    </div>
        </div>
    </div>
</body>

--------------------------------------------trac-------------------------------------------------

Page handler: <bound method Root.index of <assignment.controllers.Root
object at 0x019E90F0>>
Traceback (most recent call last):
  File "c:\python25\lib\site-packages\cherrypy-2.3.0-py2.5.egg\cherrypy\_cphttptools.py",
line 121, in _run
    self.main()
  File "c:\python25\lib\site-packages\cherrypy-2.3.0-py2.5.egg\cherrypy\_cphttptools.py",
line 264, in main
    body = page_handler(*virtual_path, **self.params)
  File "<string>", line 3, in index
  File "c:\python25\lib\site-packages\TurboGears-1.0.8-py2.5.egg\turbogears\controllers.py",
line 360, in expose
    *args, **kw)
  File "<string>", line 5, in run_with_transaction
  File "c:\python25\lib\site-packages\TurboGears-1.0.8-py2.5.egg\turbogears\database.py",
line 359, in so_rwt
    retval = func(*args, **kw)
  File "<string>", line 5, in _expose
  File "c:\python25\lib\site-packages\TurboGears-1.0.8-py2.5.egg\turbogears\controllers.py",
line 373, in <lambda>
    mapping, fragment, args, kw)))
  File "c:\python25\lib\site-packages\TurboGears-1.0.8-py2.5.egg\turbogears\controllers.py",
line 423, in _execute_func
    return _process_output(output, template, format, content_type,
mapping, fragment)
  File "c:\python25\lib\site-packages\TurboGears-1.0.8-py2.5.egg\turbogears\controllers.py",
line 88, in _process_output
    fragment=fragment)
  File "c:\python25\lib\site-packages\TurboGears-1.0.8-py2.5.egg\turbogears\view\base.py",
line 159, in render
    return engine.render(**kw)
  File "c:\python25\lib\site-packages\TurboKid-1.0.4-py2.5.egg\turbokid\kidsupport.py",
line 206, in render
    output=output, format=format)
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\__init__.py",
line 301, in serialize
    raise_template_error(module=self.__module__)
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\__init__.py",
line 299, in serialize
    return serializer.serialize(self, encoding, fragment, format)
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\serialization.py",
line 107, in serialize
    text = ''.join(self.generate(stream, encoding, fragment, format))
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\serialization.py",
line 629, in generate
    for ev, item in self.apply_filters(stream, format):
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\serialization.py",
line 165, in format_stream
    for ev, item in stream:
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\parser.py",
line 221, in _coalesce
    for ev, item in stream:
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\serialization.py",
line 477, in inject_meta_tags
    for ev, item in stream:
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\parser.py",
line 179, in _track
    for p in stream:
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\filter.py",
line 32, in apply_matches
    item = stream.expand()
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\parser.py",
line 108, in expand
    for ev, item in self._iter:
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\parser.py",
line 179, in _track
    for p in stream:
  File "c:\python25\lib\site-packages\kid-0.9.6-py2.5.egg\kid\parser.py",
line 221, in _coalesce
    for ev, item in stream:
  File "C:\Documents and
Settings\hanjie\assignment\assignment\templates\welcome.py", line 109,
in _pull
  File "<string>", line 1, in <lambda>
  File "c:\python25\lib\site-packages\SQLObject-0.10.4-py2.5.egg\sqlobject\joins.py",
line 144, in performJoin
    inst.id)
  File "c:\python25\lib\site-packages\SQLObject-0.10.4-py2.5.egg\sqlobject\dbconnection.py",
line 547, in _SO_selectJoin
    self.sqlrepr(value)))
  File "c:\python25\lib\site-packages\SQLObject-0.10.4-py2.5.egg\sqlobject\dbconnection.py",
line 696, in queryAll
    return self._dbConnection._queryAll(self._connection, s)
  File "c:\python25\lib\site-packages\SQLObject-0.10.4-py2.5.egg\sqlobject\dbconnection.py",
line 353, in _queryAll
    self._executeRetry(conn, c, s)
  File "c:\python25\lib\site-packages\SQLObject-0.10.4-py2.5.egg\sqlobject\mysql\mysqlconnection.py",
line 117, in _executeRetry
    raise OperationalError(ErrorMessage(e))
OperationalError: Unknown column 'post_table_id' in 'where clause'
Error location in template file 'C:\\Documents and
Settings\\hanjie\\assignment\\assignment\\templates\\welcome.kid'
between line 19, column 3 and line 20, column 4:
			<div class="comments">

Re: [SQLObject] Is this a bug?

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

On Mon, Mar 30, 2009 at 04:16:16PM +0200, Iwan Vosloo wrote:
> This looks like a bug - correct me if I'm wrong.  Transaction.close()
> does not close the underlying connection. Seems like the __getattr__ of
> Transaction is to blame if I understand correctly.

   I think .close() on a Transaction must be forbidden. I am going to add a
.close() method to Transaction that raises an exception saying "Do not call
close() - call either commit(), commit(close=True) or rollback()". Ok?

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

Re: [SQLObject] Bug? Spurious connection to postgresql

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

Hello! I am going to work on this. If you are still interested I'd like to
have a discussion.

On Sat, Dec 13, 2008 at 07:26:14PM +0200, Iwan Vosloo wrote:
> When you call dropTable on a SQLObject class, _inside a transaction_,
> sqlobject creates a second connection to postgresql.  This connection
> later deadlocks randomly with the first (which is sometimes busy inside
> a transaction).  
> 
> I can't figure out why the deadlock happens, but the second connection
> should never have been created to start with.
> 
> If you run the code below, you'll see that createTable works correctly.
> This code does not illustrate the deadlock, only the extra connection.
> 
> Using PDB, we've narrowed it to the following:
> 
> In pgconnection.py, line:
> 163  	        if self.server_version[:3] <= "7.2":
> 
> the attribute access to server_version results in a "poor mans
> aquisition" call to the method server_version on the Transaction's
> _dbConnection (a PostgresConnection).
> 
> In there, on line:
> 304  	            server_version = self.queryOne("SELECT version()")[0]
> 
> A query is executed on the underlying db connection.
> 
> This is where the extra connection is created (the original is already
> in a transaction at this point).

   I have never looked carefully into Transaction.__getattr__ and it seems
there is a number of clever tricks there. Too much to my taste but it's
impossible to fix it without big redesign.
   The problem with .server_version is that it's a property, so it is
called at the very beginning of said __getattr__ and 'self' is the
Connection, not the Transaction so server_version calls wrong
self.queryOne(). I think, the simplest way to fix this would be to make the
property a normal method. Then __getattr__ will wrap self and the
.server_version() method will call .queryOne() on the Transaction, not
Connection.
   This is an API change but I think it's a small evil 'cause it is a
change in an API that is hardly used by many.
   What do you think?

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

Re: [SQLObject] DateCol & DateTimecol

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

On Sun, Apr 05, 2009 at 07:26:05PM +0200, Markus W. Barth wrote:
> Sorry, Oleg, you are right, it accepts both string and datetime. I got a bit 
> misleaded by the formencode exception
> <snippet>
> formencode.api.Invalid: expected a date/time string of the '%Y-%m-%d' format 
> in the DateTimeCol 'date', got <type 'str'> '' instead
> </snippet>

   Validator/converter tries hard to convert, but if there was an exception
it assumes the exception was from strptime() due to a non-corresponding
date and format strings.

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

Re: [SQLObject] DateCol & DateTimecol

[Markus W. B. <ma...@si...>]

On Sunday 05 April 2009 15:08:37 Oleg Broytmann wrote:
> On Sun, Apr 05, 2009 at 01:02:35PM +0200, Markus W. Barth wrote:
> > The value for DateCol is set as a formatted date string
>
>    Why? You can set datetime:
>
> class Test(SQLObject):
>     date = DateCol()
>
> Test.createTable()
>
> t = Test(date=date(2001, 12, 21))
> print type(t.date), t.date
>
> t.date = date(2002, 1, 1)
> print type(t.date), t.date
>
>    Output:
>
>  1/Query   :  CREATE TABLE test (
>     id INTEGER PRIMARY KEY,
>     date DATE
> )
>  1/QueryR  :  CREATE TABLE test (
>     id INTEGER PRIMARY KEY,
>     date DATE
> )
>  2/QueryIns:  INSERT INTO test (date) VALUES ('2001-12-21')
>  2/QueryR  :  INSERT INTO test (date) VALUES ('2001-12-21')
>  3/QueryOne:  SELECT date FROM test WHERE ((test.id) = (1))
>  3/QueryR  :  SELECT date FROM test WHERE ((test.id) = (1))
> <type 'datetime.date'> 2001-12-21
>  4/Query   :  UPDATE test SET date = ('2002-01-01') WHERE id = (1)
>  4/QueryR  :  UPDATE test SET date = ('2002-01-01') WHERE id = (1)
> <type 'datetime.date'> 2002-01-01
>
> > In the docs it also says that
> > it's _usually_ returned as these data types. Does this depend on the used
> > db and is it predictable
>
>    The docs is a bit outdated. That part of the docs was written before
> DateCol got stable validator/converter. Now with the converter the returned
> value must always be datetime/mxDateTime.
>
> Oleg.

Sorry, Oleg, you are right, it accepts both string and datetime. I got a bit 
misleaded by the formencode exception
<snippet>
formencode.api.Invalid: expected a date/time string of the '%Y-%m-%d' format 
in the DateTimeCol 'date', got <type 'str'> '' instead
</snippet>

Re: [SQLObject] DateCol & DateTimecol

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

On Sun, Apr 05, 2009 at 01:02:35PM +0200, Markus W. Barth wrote:
> The value for DateCol is set as a formatted date string

   Why? You can set datetime:

class Test(SQLObject):
    date = DateCol()

Test.createTable()

t = Test(date=date(2001, 12, 21))
print type(t.date), t.date

t.date = date(2002, 1, 1)
print type(t.date), t.date

   Output:

 1/Query   :  CREATE TABLE test (
    id INTEGER PRIMARY KEY,
    date DATE
)
 1/QueryR  :  CREATE TABLE test (
    id INTEGER PRIMARY KEY,
    date DATE
)
 2/QueryIns:  INSERT INTO test (date) VALUES ('2001-12-21')
 2/QueryR  :  INSERT INTO test (date) VALUES ('2001-12-21')
 3/QueryOne:  SELECT date FROM test WHERE ((test.id) = (1))
 3/QueryR  :  SELECT date FROM test WHERE ((test.id) = (1))
<type 'datetime.date'> 2001-12-21
 4/Query   :  UPDATE test SET date = ('2002-01-01') WHERE id = (1)
 4/QueryR  :  UPDATE test SET date = ('2002-01-01') WHERE id = (1)
<type 'datetime.date'> 2002-01-01

> In the docs it also says that 
> it's _usually_ returned as these data types. Does this depend on the used db 
> and is it predictable

   The docs is a bit outdated. That part of the docs was written before
DateCol got stable validator/converter. Now with the converter the returned
value must always be datetime/mxDateTime.

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

[SQLObject] DateCol & DateTimecol

[Markus W. B. <ma...@si...>]

The value for DateCol is set as a formatted date string but returns a datetime 
(or mxDateTime)

What's the reason for this asymmetric behaviour? In the docs it also says that 
it's _usually_ returned as these data types. Does this depend on the used db 
and is it predictable or do you have to check the datatype to make sure your 
code runs no matter where?

Thanks for explanations
markus

Re: [SQLObject] Another bug? Inheritance / splicing and threadConnection

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

Hello.

On Sun, Dec 14, 2008 at 08:45:00AM +0200, Iwan Vosloo wrote:
> allt = TestMe.select(connection=conn)
> t0 = allt[0]  # Here it complains about threadConnection not being set
>               # But, the select above WAS done with an explicit one...

   I think I fixed the bug in the revisions 3839-3841 (branches 0.9, 0.10
and the trunk). Will be in the next round of releases.

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

Re: [SQLObject] How do I find this?

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

On Mon, Mar 30, 2009 at 07:14:52PM +0400, Oleg Broytmann wrote:
>    Pretty normal situations that manipulate with sys.path.

   Sorry, that should be

"Pretty normal situations *in programs* that manipulate with sys.path."

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

Re: [SQLObject] How do I find this?

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

On Mon, Mar 30, 2009 at 05:00:42PM +0200, Iwan Vosloo wrote:
> (Pdb) value.__class__
> <class 'decimal.Decimal'>
> 
> And yet:
> (Pdb) value.__class__ is Decimal
> False
> 
> Seems like the imported Decimal and the Decimal of which value is an
> instance are not the same thing.
> 
> Specifically, the imported Decimal seems to the the "right" one, since:
> (Pdb) Decimal is getattr(sys.modules['decimal'],'Decimal')
> True
> 
> Where does the Decimal class come from, of which value is an instance?

   Pretty normal situations that manipulate with sys.path. One can easily
imports a module two times:

>>> import sys, os, decimal
>>> decimal.__file__
'/usr/lib/python2.5/decimal.pyc'
>>> os.chdir('/usr/lib/python2.5')
>>> sys.path.insert(0, '.')
>>> del sys.modules['decimal']
>>> import decimal as decimal2
>>> decimal2.__file__
'./decimal.pyc'
>>> decimal.Decimal is decimal2.Decimal
False

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

[SQLObject] How do I find this?

[Iwan V. <iw...@re...>]

Hi there.  

We are struggling with a bug which I am not sure how to track down
further.  This may not be related to sqlobject, but sqlobject is where
the trail starts.

We have a set of tests which ran fine previously - when separate test
runs used to happen in separate processes. Now, however, we run more
test runs together in the same process and get a breakage that does not
make sense.  Any pointers as to how we should hunt this thing down would
be appreciated:

The breakage happens in sqlobject's col.py, in method to_python of
DecimalValidator.  The method gets called with a value which is an
instance of a decimal.Decimal class, yet the code gets through to the
try: statement right at the end of the function.  (It should have been
caught earlier.)  The reason it is not caught earlier is because (from
pdb):

(Pdb) value.__class__
<class 'decimal.Decimal'>

And yet:
(Pdb) value.__class__ is Decimal
False

Seems like the imported Decimal and the Decimal of which value is an
instance are not the same thing.

Specifically, the imported Decimal seems to the the "right" one, since:
(Pdb) Decimal is getattr(sys.modules['decimal'],'Decimal')
True

Where does the Decimal class come from, of which value is an instance?
Does sqlobject do anything funny when constructing these?  Or should I
look beyond sqlobject?  

(We're using postgresql 8.3 and psycopg2 also.)

Thanks
- Iwan Vosloo

Re: [SQLObject] Is this a bug?

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

On Mon, Mar 30, 2009 at 04:16:16PM +0200, Iwan Vosloo wrote:
> This looks like a bug - correct me if I'm wrong.  Transaction.close()
> does not close the underlying connection.

   You can do it as tnx.commit(close=True)

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

[SQLObject] Is this a bug?

[Iwan V. <iw...@re...>]

Hi there,

I am on sqlobject 0.9.1.

This looks like a bug - correct me if I'm wrong.  Transaction.close()
does not close the underlying connection. Seems like the __getattr__ of
Transaction is to blame if I understand correctly.  Here is some code
showing the problem (fill in the xxx es):

import sqlobject

connectionURI = 'postgres://xxx:xxx@localhost/xxx'
conn = sqlobject.connectionForURI(connectionURI).transaction()


conn.close()

assert conn._connection.closed, 'The underlying connection is open'

If you follow this with:
conn._connection.close()

Then things seems to work.

Regards
- Iwan