DateCol & DateTimecol

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: DateCol & DateTimecol

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))

Re: DateCol & DateTimecol

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))

Re: DateCol & DateTimecol

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/            phd <at> phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

------------------------------------------------------------------------------

Re: Is this a bug?

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/            phd <at> phd.pp.ru
           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

Re: Bug? Spurious connection to postgresql

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

A problem about "ForeignKey", help!!

------------------------------------------------------------------------------
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
sqlobject-discuss <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Re: A problem about "ForeignKey", help!!

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/            phd <at> phd.pp.ru
           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

Re: A problem about "ForeignKey", help!!

------------------------------------------------------------------------------
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
sqlobject-discuss <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

ForeignKey

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

------------------------------------------------------------------------------
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