transactions; cache sync behavior; sqlite3 relatet?

Hi!

Attached is a small code snippet highlighting some strange behavior.
It outputs:

Writing 'connection_val' to connection foo
Value of transaction foo: 'init'
Writing 'transaction_val' to transaction foo
Value of connection foo: 'connection_val'

Instead of the expected:

Writing 'connection_val' to connection foo
Value of transaction foo: 'connection_val'
Writing 'transaction_val' to transaction foo
Value of connection foo: 'connection_val'

Is this behavior intentional? (ie can I rely on it)
Is is sqlite3 related? (right now I can't test it on another DB)

How should I fix this?
.expire()? .sync()?
Invalidate the transaction's cache?

Caching behavior in sqlobject looks like some can worms to me.

regards
Herwig Hochleitner

Vacation

Hello! I'm leaving the town for a vacation. Will be back at June 20. Please
help each other.

Oleg.
--

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

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get

Re: transactions; cache sync behavior; sqlite3 relatet?

I'll try to answer briefly and then will leave the computer...

On Fri, Jun 05, 2009 at 11:21:49PM +0200, Herwig Hochleitner wrote:
> Writing 'connection_val' to connection foo
> Value of transaction foo: 'init'
> Writing 'transaction_val' to transaction foo
> Value of connection foo: 'connection_val'

> import sqlobject
> # Turn off caching so that multiple connections (ie transactions) sync properly
> conn = sqlobject.connectionForURI("sqlite:/:memory:", debug=True, logger="database.query",
loglevel="debug", cache=False)
> class Dummy(sqlobject.SQLObject):
>     foo = sqlobject.StringCol()
> Dummy.createTable(connection=conn)
> Dummy(foo="init", connection=conn)
> tr = conn.transaction()
> conn_dummy=Dummy.get(1,conn)
> trans_dummy=Dummy.get(1,tr)
> print "Writing 'connection_val' to connection foo"
> conn_dummy.foo = "connection_val"
> print "Value of transaction foo: '%s'" % trans_dummy.foo

   AFAIU, what is going on there is:

-- the code opens the first connection (without a transaction);
-- a new table is created via connection 1;
-- a new row is inserted via connection 1;
-- the code opens another connection, and BEGINs a transaction ;
-- the code draws two copies of the row via connection1 and connection2;

Re: transactions; cache sync behavior; sqlite3 relatet?

Thanks for your answer

I messed up the code snippet; forgot the commit.
Please check updated attachment.
>    AFAIU, what is going on there is:
>
> -- the code opens the first connection (without a transaction);
> -- a new table is created via connection 1;
> -- a new row is inserted via connection 1;
> -- the code opens another connection, and BEGINs a transaction ;
> -- the code draws two copies of the row via connection1 and connection2;
> -- the code changes the attribute .foo of the FIRST copy;
> -- the code prints the attribute .foo of the SECOND copy that was drawn via
>    another transaction, and the value is still 'init' because it isn't
>    changed - the code hasn't changed trans_dummy.foo yet.
>   
I intended to illustrate following behavior:

Two instances of the same class with same id; one pulled via a 
connection (with cache=False); one pulled via a transaction createt from 
that same connection;
--> Commits to the transaction _do_ invalidate the instance pulled via 
connection (thanks to cache=False);
--> Changes to the connection instance _don't_ invalidate the 
transaction instance;

This asymmetric behavior seems strange to me, since (as far as i 
understood the code), the transaction object even uses the same cache; 
it's using the same DBConnection instance, after all.

Re: Vacation

> Hello! I'm leaving the town for a vacation. Will be back at June 20. Please
> help each other.
>
> Oleg.

Have fun!

Cheers,
Daniel

--

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects

longId=True handling...

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects

_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Quoting reserved column names...

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects

_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Re: longId=True handling...

On Thu, Jun 11, 2009 at 3:06 AM, Sam's Lists<samslists <at> gmail.com> wrote:
> How can I make sqlObject seemlessly let me refer to columns named in
> the long style just using id?

I think this is more of a Python question than a SQLObject question,
although it may be a little trickier in the SQLObject case because
SQLObject already uses a lot of attribute magic.  One approach might
be to just add .id properties to all your classes:

>>> class EventQueueID(object):
...     def __init__(self):
...         self.EventQueueID = 5
...

>>> e = EventQueueID()
>>> e.id
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'EventQueueID' object has no attribute 'id'

>>> def getid(self):
...     return getattr(self, self.__class__.__name__)
...
>>> def setid(self, x):
...     return setattr(self, self.__class__.__name__, x)
...
>>> EventQueueID.id = property(fget=getid, fset=setid)

>>> e.id
5
>>> e.id = 7
>>> e.id
7

I don't know if SQLObject has any magic that would break this, but I
think it should work.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects

Re: Quoting reserved column names...

Sam's Lists escribió:
> So I keep humming along on this upgrade of someone else's code from 
> old versions of SQLObject and Mysql to the current SQLObject and MySQL 
> 5...
>
> The current problem is that I have a table with the column name 
> 'condition' which apparently is not a reserved word in MySQL 4.0 but 
> is a reserved word in 5.0.
>
> When SQLObject translates its stuff to sql it does not put quotes
> around the column names.  If it only would everything would work fine.
>
> I could rename the column, but the word is used a lot in the program
> in different ways, so it will get confusing to make sure I only change
> the right ones .
>
> Is there a way to force SQLObject to quote it properly?
>
you can force the name of the column in the database this way:

condition = StringCol(dbName='_condition')

> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> ------------------------------------------------------------------------
>
> _______________________________________________
> sqlobject-discuss mailing list
> sqlobject-discuss <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>   

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects

Call a function in a schema

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects

_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss