sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Inheritance looses column

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

[to the list...]

On Mon, Sep 07, 2009 at 01:34:51PM +0200, Tobias Weber wrote:
> On 07.09.2009, at 11:15, Oleg Broytmann wrote:
>
>> I don't think it's inconsistent.
>
> Well, getting a parent's column sometimes works and sometimes doesn't  

   Yes, you have a point.

> (depending on the cache?)

   Depending on if the entire tree of inheritable objects has been fetched.
Or if you access an attribute that was or was not fetched.

>> Any property is free to raise any exception.
>
> During normal operation descriptors are only supposed to raise  
> AttributeError (which this one does). Whether reading a field at that  
> point constitutes an allowed operation depends on the documentation of  
> _init. I didn't find much, but then it's a bit hard to search for ;)

   :(

>> Looks like a bug in that library.
>
> http://bugs.python.org/issue1785
>
> This solves my problem!

   Aha, that's better!

> I'm still not sure if SQLObject is behaving correctly, though. What's  
> the point of _init if you can't access data yet?

   In this particular case _init is called in the middle of fetching
children. InheritableIteration.next() calls obj.get() which in turn calls
parent.get(), etc; every .get() calls _init, but to access all attributes
you have to wait until all .get's are finished.

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

Re: [SQLObject] Inheritance looses column

[Tobias W. <to...@gm...>]

[forgot to "Reply All"]

On 07.09.2009, at 11:15, Oleg Broytmann wrote:

> I don't think it's inconsistent.

Well, getting a parent's column sometimes works and sometimes doesn't  
(depending on the cache?)

> Any property is free to raise any exception.

During normal operation descriptors are only supposed to raise  
AttributeError (which this one does). Whether reading a field at that  
point constitutes an allowed operation depends on the documentation of  
_init. I didn't find much, but then it's a bit hard to search for ;)

> Looks like a bug in that library.

http://bugs.python.org/issue1785

This solves my problem!

I'm still not sure if SQLObject is behaving correctly, though. What's  
the point of _init if you can't access data yet?

Re: [SQLObject] Inheritance looses column

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

On Mon, Sep 07, 2009 at 09:12:14AM +0200, Tobias Weber wrote:
> On 07.09.2009, at 00:29, Oleg Broytmann wrote:
> 
> > Now, much later after _init(), the instance of class C got the  
> > attribute 'name'.
> 
> I know. The problem is that dir() lists it before that, which, as I  
> wrote, breaks any code using introspection.

   dir() didn't list *it* - dir() listed a property from the class - print
self.__class__.__dict__ and see it's there. But having a property in the
class doesn't guarantee it wouldn't raise an exception when called. In case
of properties dir() is not a substitute for hasattr().

> SQLObject passes  
> internally inconsistent objects to _init.

   I don't think it's inconsistent. Any property is free to raise any
exception. Think about a property that raises UnicodeError, or
socket.error, or KeyboardInterrupt.

> In my case, a library implementing the observer pattern looks for a  
> certain kind of method using a module that comes with Python:
> 
> inspect.getmembers(self, predicate=lambda m: inspect.ismethod(m))
> 
> Internally that iterates over dir() and does isinstance(getattr).

   Looks like a bug in that library. It must distinguish plain attributes
from properties.

> Code  
> like this should never fail.

   Really? Even if dir() detects a property that raises an exception? Any
exception?

> The ugly part is that the reason dir() mentions 'name' is because it's  
> in the __dict of the parent class, as a StringCol instance. Normally  
> getattr does search there and would just return that StringCol. I  
> guess the error stems from SQLObject overriding __getattribute__ or  
> something with an implementation that is aware of columns, but at the  
> time of _init is not defined. I think it should at all times behave  
> like a normal Python object and just return StringCol if it doesn't  
> have a value from the table yet.

   I don't think so. After you have declared 'name' is a StringCol
self.name is supposed to be a property that accepts and returns strings,
not the StringCol instance. What are you going to do with those StringCol
instances?

> Or also override __dir__ and only  
> list magic members when they actually work.

   Impossible now - __dir__ is only used in Python 2.6+, and SQLObject still
supports 2.4.
   And I don't think it's necessary. Any property is free to raise any
exception.

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

Re: [SQLObject] Inheritance looses column

[Tobias W. <to...@gm...>]

On 07.09.2009, at 00:29, Oleg Broytmann wrote:

> Now, much later after _init(), the instance of class C got the  
> attribute 'name'.

I know. The problem is that dir() lists it before that, which, as I  
wrote, breaks any code using introspection. SQLObject passes  
internally inconsistent objects to _init.

In my case, a library implementing the observer pattern looks for a  
certain kind of method using a module that comes with Python:

inspect.getmembers(self, predicate=lambda m: inspect.ismethod(m))

Internally that iterates over dir() and does isinstance(getattr). Code  
like this should never fail.

The ugly part is that the reason dir() mentions 'name' is because it's  
in the __dict of the parent class, as a StringCol instance. Normally  
getattr does search there and would just return that StringCol. I  
guess the error stems from SQLObject overriding __getattribute__ or  
something with an implementation that is aware of columns, but at the  
time of _init is not defined. I think it should at all times behave  
like a normal Python object and just return StringCol if it doesn't  
have a value from the table yet. Or also override __dir__ and only  
list magic members when they actually work.

Re: [SQLObject] Inheritance looses column

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

On Mon, Sep 07, 2009 at 02:10:42AM +0400, Oleg Broytmann wrote:
>    Aha, now I see. I got the exception for the second time. 'name' is in
> dir(self) because it came from the class, but it's not in self.__dict__.
> Seems like a bug.

   Well, got it. Not a bug in SQLObject, but a "bug" in your expectations. :)
Let' see.

 1/Select  :  SELECT a.id, a.child_name FROM a WHERE ((a.child_name) = ('B'))
 1/QueryR  :  SELECT a.id, a.child_name FROM a WHERE ((a.child_name) = ('B'))
 1/Select children of the class B:  SELECT b.id, b.name, b.child_name FROM b WHERE ((b.id) IN (1, 2, 3))
 1/QueryR  :  SELECT b.id, b.name, b.child_name FROM b WHERE ((b.id) IN (1, 2, 3))
<class '__main__.A'>
<class '__main__.B'>
X
 2/QueryOne:  SELECT child_name FROM c WHERE ((c.id) = (1))
 2/QueryR  :  SELECT child_name FROM c WHERE ((c.id) = (1))
 2/COMMIT  :  auto
<class '__main__.C'>
Traceback (most recent call last):
   ...

   You see - SQLObject SELECTs data for the class C. But the table for the
class is empty, 'name' is in class B. During _init() the class is not yet
fully drawn from the database, so there is no 'name' in it yet.
   Let's wait and see if SQLObject SELECTs the additional data for the
class C from the tables for its parent classes. Let's comment out your
getattr (and replace it with 'pass'):

 1/Select  :  SELECT a.id, a.child_name FROM a WHERE ((a.child_name) = ('B'))
 1/QueryR  :  SELECT a.id, a.child_name FROM a WHERE ((a.child_name) = ('B'))
 1/Select children of the class B:  SELECT b.id, b.name, b.child_name FROM b WHERE ((b.id) = (1))
 1/QueryR  :  SELECT b.id, b.name, b.child_name FROM b WHERE ((b.id) = (1))
<class '__main__.A'>
<class '__main__.B'>
 2/QueryOne:  SELECT child_name FROM c WHERE ((c.id) = (1))
 2/QueryR  :  SELECT child_name FROM c WHERE ((c.id) = (1))
 2/COMMIT  :  auto
<class '__main__.C'>
 1/COMMIT  :  auto
[<C 1 name='X'>]

   Now, much later after _init(), the instance of class C got the attribute
'name'.

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

Re: [SQLObject] Inheritance looses column

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

[Answering to the list...]

On Sun, Sep 06, 2009 at 11:27:12PM +0200, Tobias Weber wrote:
> On 06.09.2009, at 15:33, Oleg Broytmann wrote:
>
>> No exception.
>
> That's 'cause you didn't run it twice. I wrote that the problem only  
> manifests when retrieving records from the database that do not yet  
> exist in memory.

   Aha, now I see. I got the exception for the second time. 'name' is in
dir(self) because it came from the class, but it's not in self.__dict__.
Seems like a bug.

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

Re: [SQLObject] Inheritance looses column

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

On Sun, Sep 06, 2009 at 09:54:43AM +0200, Tobias Weber wrote:
> class A(InheritableSQLObject):
>     def _init(self, *args, **kargs):
>         InheritableSQLObject._init(self, *args, **kargs)
>         print self.__class__
>         if 'name' in dir(self):
>             # This should never fail
>             print getattr(self, 'name')
> 
> class B(A):
>     name = sqlobject.StringCol()
> 
> class C(B):
>     pass
> 
> sqlobject.sqlhub.processConnection = sqlobject.connectionForURI('sqlite:/tmp/x')
> 
> for klass in (A, B, C):
>     klass.createTable(ifNotExists = True)

   Works for me:

print list(B.select())
C(name = 'X')
print list(B.select())

   prints

 1/QueryOne:  SELECT tbl_name FROM sqlite_master WHERE type='table' AND tbl_name = 'a'
 1/QueryR  :  SELECT tbl_name FROM sqlite_master WHERE type='table' AND tbl_name = 'a'
 2/Query   :  CREATE TABLE a (
    id INTEGER PRIMARY KEY,
    child_name VARCHAR (255)
)
 2/QueryR  :  CREATE TABLE a (
    id INTEGER PRIMARY KEY,
    child_name VARCHAR (255)
)
 3/QueryOne:  SELECT tbl_name FROM sqlite_master WHERE type='table' AND tbl_name = 'b'
 3/QueryR  :  SELECT tbl_name FROM sqlite_master WHERE type='table' AND tbl_name = 'b'
 4/Query   :  CREATE TABLE b (
    id INTEGER PRIMARY KEY,
    name TEXT,
    child_name VARCHAR (255)
)
 4/QueryR  :  CREATE TABLE b (
    id INTEGER PRIMARY KEY,
    name TEXT,
    child_name VARCHAR (255)
)
 5/QueryOne:  SELECT tbl_name FROM sqlite_master WHERE type='table' AND tbl_name = 'c'
 5/QueryR  :  SELECT tbl_name FROM sqlite_master WHERE type='table' AND tbl_name = 'c'
 6/Query   :  CREATE TABLE c (
    id INTEGER PRIMARY KEY,
    child_name VARCHAR (255)
)
 6/QueryR  :  CREATE TABLE c (
    id INTEGER PRIMARY KEY,
    child_name VARCHAR (255)
)
 7/Select  :  SELECT a.id, a.child_name FROM a WHERE ((a.child_name) = ('B'))
 7/QueryR  :  SELECT a.id, a.child_name FROM a WHERE ((a.child_name) = ('B'))
[]
 8/QueryIns:  INSERT INTO a (child_name) VALUES ('B')
 8/QueryR  :  INSERT INTO a (child_name) VALUES ('B')
 9/QueryOne:  SELECT child_name FROM a WHERE ((a.id) = (1))
 9/QueryR  :  SELECT child_name FROM a WHERE ((a.id) = (1))
<class '__main__.A'>
10/QueryIns:  INSERT INTO b (id, name, child_name) VALUES (1, 'X', 'C')
10/QueryR  :  INSERT INTO b (id, name, child_name) VALUES (1, 'X', 'C')
11/QueryOne:  SELECT name, child_name FROM b WHERE ((b.id) = (1))
11/QueryR  :  SELECT name, child_name FROM b WHERE ((b.id) = (1))
<class '__main__.B'>
X
12/QueryIns:  INSERT INTO c (id, child_name) VALUES (1, NULL)
12/QueryR  :  INSERT INTO c (id, child_name) VALUES (1, NULL)
13/QueryOne:  SELECT child_name FROM c WHERE ((c.id) = (1))
13/QueryR  :  SELECT child_name FROM c WHERE ((c.id) = (1))
<class '__main__.C'>
X
14/Select  :  SELECT a.id, a.child_name FROM a WHERE ((a.child_name) = ('B'))
14/QueryR  :  SELECT a.id, a.child_name FROM a WHERE ((a.child_name) = ('B'))
14/Select children of the class B:  SELECT b.id, b.name, b.child_name FROM b WHERE ((b.id) = (1))
14/QueryR  :  SELECT b.id, b.name, b.child_name FROM b WHERE ((b.id) = (1))
[<C 1 name='X'>]

   No exception.

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

[SQLObject] Inheritance looses column

[Tobias W. <to...@gm...>]

Hi,
as I understand the documentation, sub-sub-classing  
InheritableSQLObject should be fine. But it messes with introspection,  
as demonstrated by the short attached script.

When there is no C and you create and retrieve B, everything works.  
Introduce C, and running it with an empty database (rm /tmp/x) still  
works:

<class '__main__.A'>
<class '__main__.B'>
X
<class '__main__.C'>
X

But run it again, so that the first list() actually does retrieve  
something, and it will raise:

<class '__main__.A'>
<class '__main__.B'>
X
<class '__main__.C'>
Traceback (most recent call last):
   File "desperate.py", line 23, in <module>
     list(B.select())
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/ 
lib/python2.6/site-packages/SQLObject-0.12dev_r3970-py2.6.egg/ 
sqlobject/sresults.py", line 179, in __iter__
     return iter(list(self.lazyIter()))
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/ 
lib/python2.6/site-packages/SQLObject-0.12dev_r3970-py2.6.egg/ 
sqlobject/inheritance/iteration.py", line 43, in next
     childResults=childResults, connection=self.dbconn)
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/ 
lib/python2.6/site-packages/SQLObject-0.12dev_r3970-py2.6.egg/ 
sqlobject/inheritance/__init__.py", line 309, in get
     selectResults=childResults)
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/ 
lib/python2.6/site-packages/SQLObject-0.12dev_r3970-py2.6.egg/ 
sqlobject/inheritance/__init__.py", line 309, in get
     selectResults=childResults)
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/ 
lib/python2.6/site-packages/SQLObject-0.12dev_r3970-py2.6.egg/ 
sqlobject/inheritance/__init__.py", line 290, in get
     val = super(InheritableSQLObject, cls).get(id, connection,  
selectResults)
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/ 
lib/python2.6/site-packages/SQLObject-0.12dev_r3970-py2.6.egg/ 
sqlobject/main.py", line 893, in get
     val._init(id, connection, selectResults)
   File "/Users/towb/Desktop/desperate.py", line 10, in _init
     print getattr(self, 'name')
   File "<string>", line 1, in <lambda>
AttributeError: 'NoneType' object has no attribute 'name'

I couldn't find out what actually happens as the code is full of  
eval()...

Re: [SQLObject] This transaction has already gone through ROLLBACK

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

On Thu, Sep 03, 2009 at 01:33:53PM +0200, Sophana K wrote:
> > > It looks like its related with the mysql server being overloaded. But
> >
> >    I think you mean "restarted", not "overloaded", right?
> >
> > No, the mysql server is very loaded.

   Then how it's related to SQLObject? Timeouts between clients and the
server?

> > > I still don't understand why.
> > > I've been looking at the source and don't understand how this can
> > > happen. I never call rollback in my source, and always make
> > > transactions through doInTransaction.
> >
> >    doInTransaction() calls rollback() on any exception.
> >
> > I understand this.
> rollBack is called on a Transaction object by doInTransaction.
> But it just throws away the object just after, doesn't it?
> This is why I don't understand how it can happen if I don't explicitely call
> rollback myself.
> Could it happen during the contruction of the Transaction object itself?
> As you might see in the traceback, the error happens while the Transaction
> is created.

   The only place I could suspect is the call dbConnection.getConnection()
in Transaction.__init__().

> I forgot to say. It looks that once this happened once, all upcoming
> transactions fail the same way.
> 
> In the Transaction constructor:
> class Transaction(object):
>     def __init__(self, dbConnection):
>         # this is to skip __del__ in case of an exception in this __init__
>         self._obsolete = True
>         self._dbConnection = dbConnection
>         self._connection = dbConnection.getConnection()
>         self._dbConnection._setAutoCommit(self._connection, 0)
>         self.cache = CacheSet(cache=dbConnection.doCache)
>         self._deletedCache = {}
>         self._obsolete = False
> 
> _obsolete is set to True.
> Then you have self._connection accessed.
> So the __getattr__ method should be called, doesn't it?
> __getattr__ first calls self.assertActive() which checks that _obsolete is
> False.

   No, self._connection is assigned:
self._connection = dbConnection.getConnection(). After this __getattr__ is
never called on accessing the self._connection. __getattr__ is called on
accessing non-existing attributes. In the Transaction class it is used to
delegate attribute access to the underlying connection.

> >    What connection have you assigned to hubNoCache? It seems it's a (rolled
> > back) transaction, not a simple connection.
> >
> >
> hubNoCache=ConnectionHub()
> hubNoCache.processConnection = connectionForURI(database+'&cache=')

   Looks good, nothing strange here. Could it be an old transaction is
stuck in  hubNoCache?

> > > In the traceback I don't understand why there are missing step between
> > > conn = old_conn.transaction() and self.assertActive(). It should go
> > > through the Transaction constructor.

   I recommend you to investigate it deeper: add a lot of debugging output
to the dbconnection.py to find out what is the connection, what is the
transaction and what is the attribute that cause the problem.

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

Re: [SQLObject] This transaction has already gone through ROLLBACK

[Sophana K <sop...@gm...>]

>
>
> > It looks like its related with the mysql server being overloaded. But
>
>    I think you mean "restarted", not "overloaded", right?
>
> No, the mysql server is very loaded.


> > I still don't understand why.
> > I've been looking at the source and don't understand how this can
> > happen. I never call rollback in my source, and always make
> > transactions through doInTransaction.
>
>    doInTransaction() calls rollback() on any exception.
>
> I understand this.
rollBack is called on a Transaction object by doInTransaction.
But it just throws away the object just after, doesn't it?
This is why I don't understand how it can happen if I don't explicitely call
rollback myself.
Could it happen during the contruction of the Transaction object itself?
As you might see in the traceback, the error happens while the Transaction
is created.
My code isn't called yet...

I forgot to say. It looks that once this happened once, all upcoming
transactions fail the same way.

In the Transaction constructor:
class Transaction(object):
    def __init__(self, dbConnection):
        # this is to skip __del__ in case of an exception in this __init__
        self._obsolete = True
        self._dbConnection = dbConnection
        self._connection = dbConnection.getConnection()
        self._dbConnection._setAutoCommit(self._connection, 0)
        self.cache = CacheSet(cache=dbConnection.doCache)
        self._deletedCache = {}
        self._obsolete = False

_obsolete is set to True.
Then you have self._connection accessed.
So the __getattr__ method should be called, doesn't it?
__getattr__ first calls self.assertActive() which checks that _obsolete is
False.
So I wonder how this can work?



> > In the traceback I don't understand why there are missing step between
> > conn = old_conn.transaction() and self.assertActive(). It should go
> > through the Transaction constructor.
>
>    What connection have you assigned to hubNoCache? It seems it's a (rolled
> back) transaction, not a simple connection.
>
>
hubNoCache=ConnectionHub()
hubNoCache.processConnection = connectionForURI(database+'&cache=')

Re: [SQLObject] This transaction has already gone through ROLLBACK

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

On Thu, Sep 03, 2009 at 10:26:03AM +0200, Sophana K wrote:
>   File "/usr/lib/python2.5/site-packages/SQLObject-0.10.2-py2.5.egg/sqlobject/dbconnection.py",
> line 856, in doInTransaction
>     conn = old_conn.transaction()
>   File "/usr/lib/python2.5/site-packages/SQLObject-0.10.2-py2.5.egg/sqlobject/dbconnection.py",
> line 754, in __getattr__
>     self.assertActive()
>   File "/usr/lib/python2.5/site-packages/SQLObject-0.10.2-py2.5.egg/sqlobject/dbconnection.py",
> line 678, in assertActive
>     assert not self._obsolete, "This transaction has already gone
> through ROLLBACK; begin another transaction"
> AssertionError: This transaction has already gone through ROLLBACK;
> begin another transaction
> 
> It looks like its related with the mysql server being overloaded. But

   I think you mean "restarted", not "overloaded", right?

> I still don't understand why.
> I've been looking at the source and don't understand how this can
> happen. I never call rollback in my source, and always make
> transactions through doInTransaction.

   doInTransaction() calls rollback() on any exception.

> In the traceback I don't understand why there are missing step between
> conn = old_conn.transaction() and self.assertActive(). It should go
> through the Transaction constructor.

   What connection have you assigned to hubNoCache? It seems it's a (rolled
back) transaction, not a simple connection.

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

[SQLObject] This transaction has already gone through ROLLBACK

[Sophana K <sop...@gm...>]

Hello

I'm using transactions in sqlobjects since years in my web application.
But since some months, I receive these exceptions:

in update
    hubNoCache.doInTransaction(updateSubscr,self.id)
  File "/usr/lib/python2.5/site-packages/SQLObject-0.10.2-py2.5.egg/sqlobject/dbconnection.py",
line 856, in doInTransaction
    conn = old_conn.transaction()
  File "/usr/lib/python2.5/site-packages/SQLObject-0.10.2-py2.5.egg/sqlobject/dbconnection.py",
line 754, in __getattr__
    self.assertActive()
  File "/usr/lib/python2.5/site-packages/SQLObject-0.10.2-py2.5.egg/sqlobject/dbconnection.py",
line 678, in assertActive
    assert not self._obsolete, "This transaction has already gone
through ROLLBACK; begin another transaction"
AssertionError: This transaction has already gone through ROLLBACK;
begin another transaction

It looks like its related with the mysql server being overloaded. But
I still don't understand why.
I've been looking at the source and don't understand how this can
happen. I never call rollback in my source, and always make
transactions through doInTransaction.

In the traceback I don't understand why there are missing step between
conn = old_conn.transaction() and self.assertActive(). It should go
through the Transaction constructor.

Please help.

Re: [SQLObject] SQLite backend choosing (was: Precedence of manually installed pysqlite)

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

On Thu, Nov 27, 2008 at 11:07:31PM +0100, Markus Gritsch wrote:
> On Thu, Nov 27, 2008 at 10:09 PM, Dan Pascu <da...@ag...> wrote:
> > On Thursday 27 November 2008, Oleg Broytmann wrote:
> >> > Or maybe some parameter to the dburi (like backend) would be simpler
> >> > and cleaner.
> >>
> >>    Either sqlite2://, sqlite3:// - or sqlite://...?backend=sqlite2.
> >
> > My preference would be towards the last example using a backend parameter
> 
> Me too.  Using 'sqlite2' as name is IMO not correct.  'pysqlite2'
> would be more appropriate but this makes it look weird at the URI
> beginning.  Appending ?backend=sqlite3 or ?backend=pysqlite2 looks
> nice.

   Done in revision 3967. Will be in 0.12.

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

Re: [SQLObject] FW: Newbie Problems connecting sqlite

[Joaquin A. M. <gat...@ho...>]

Thanks, it worked.I had tried with  "sqlite:/C|/full/path/to/database"as indicated in the documentation but it did not work.J.
> Date: Mon, 24 Aug 2009 13:37:59 +0200
> From: jon...@fa...
> To: gat...@ho...
> CC: sql...@li...
> Subject: Re: [SQLObject] FW: Newbie Problems connecting sqlite
> 
> Joaquin Abian Monux escribió:
> > Hi,
> > I am probably doing something very wrong, but I can not discover what 
> > it is.
> > I googled and checked the archives but I did not found any hint.
> > I am new to SQLObject (although experienced in python and databases).
> > I was trying to follow the examples in the documentation but when 
> > executing the following code, identical to the one in the examples 
> > (except for the name of the database):
> 
> Recently I used that snippet to connect to a database in ./data/aci.sqlite
> 
>     import os
>    
>     if os.name == 'nt':
>         dsn = 'sqlite:/' + os.path.abspath('./data/aci.sqlite')
>         dsn = dsn.replace(":\\", "|\\")
>     elif os.name == 'posix':
>         dsn = 'sqlite://' + os.path.abspath(os.path.join('data', 
> 'aci.sqlite'))
> 
> 
> 
> 
> jonhattan
> >
> > *********************************
> > from sqlobject import *
> > import os
> >
> > db_filename = os.path.abspath('data_2.db')
> > if os.path.exists(db_filename):
> >     os.unlink(db_filename)
> >
> > connection_string = 'sqlite:' + db_filename
> > connection = connectionForURI(connection_string)
> > sqlhub.processConnection = connection
> >
> > class Person(SQLObject):
> >     name = StringCol()
> >
> > Person.createTable()
> > **********************************************************
> >
> > I get : "AssertionError: URIs must start with scheme:/ -- you did not 
> > include a / (in 'C:\\Python25\\programas\\ignasi_06\\data_2.db')"
> >
> > Then I used 
> > "connection_string = 'sqlite:/' + db_filename" or
> > "connection_string = 'sqlite:///' + db_filename"
> >
> > but I got in both cases: "sqlite3.OperationalError: unable to open 
> > database file"
> >
> > I tried several ways but neither run. Please help, and be nice if i am 
> > missing something obvious (as I suspect)
> > In running the new SQLObject 0.11.0 with python 2.5.4 in windows XP.
> >
> > Thanks
> >
> > Joaquin
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> > Comparte tu Facebook con tus amigos de Messenger ¡Descubre cómo! 
> > <http://www.vivelive.com/feedfacebook/>
> > ------------------------------------------------------------------------
> > ¿Quieres los nuevos emoticonos en 3D? ¡Descárgatelos gratis! 
> > <http://www.vivelive.com/emoticonos3d/index2.html>
> > ------------------------------------------------------------------------
> >
> > ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> > trial. Simplify your report design, integration and deployment - and focus on 
> > what you do best, core application coding. Discover what's new with 
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > sqlobject-discuss mailing list
> > sql...@li...
> > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> >   
> 

_________________________________________________________________
Toda la información meteorológica. Consulta en MSN el tiempo que va a hacer en cualquier lugar de España o del Mundo. 
http://eltiempo.es.msn.com/

Re: [SQLObject] FW: Newbie Problems connecting sqlite

[jonhattan <jon...@fa...>]

Joaquin Abian Monux escribió:
> Hi,
> I am probably doing something very wrong, but I can not discover what 
> it is.
> I googled and checked the archives but I did not found any hint.
> I am new to SQLObject (although experienced in python and databases).
> I was trying to follow the examples in the documentation but when 
> executing the following code, identical to the one in the examples 
> (except for the name of the database):

Recently I used that snippet to connect to a database in ./data/aci.sqlite

    import os
   
    if os.name == 'nt':
        dsn = 'sqlite:/' + os.path.abspath('./data/aci.sqlite')
        dsn = dsn.replace(":\\", "|\\")
    elif os.name == 'posix':
        dsn = 'sqlite://' + os.path.abspath(os.path.join('data', 
'aci.sqlite'))




jonhattan
>
> *********************************
> from sqlobject import *
> import os
>
> db_filename = os.path.abspath('data_2.db')
> if os.path.exists(db_filename):
>     os.unlink(db_filename)
>
> connection_string = 'sqlite:' + db_filename
> connection = connectionForURI(connection_string)
> sqlhub.processConnection = connection
>
> class Person(SQLObject):
>     name = StringCol()
>
> Person.createTable()
> **********************************************************
>
> I get : "AssertionError: URIs must start with scheme:/ -- you did not 
> include a / (in 'C:\\Python25\\programas\\ignasi_06\\data_2.db')"
>
> Then I used 
> "connection_string = 'sqlite:/' + db_filename" or
> "connection_string = 'sqlite:///' + db_filename"
>
> but I got in both cases: "sqlite3.OperationalError: unable to open 
> database file"
>
> I tried several ways but neither run. Please help, and be nice if i am 
> missing something obvious (as I suspect)
> In running the new SQLObject 0.11.0 with python 2.5.4 in windows XP.
>
> Thanks
>
> Joaquin
>
>
>
>
> ------------------------------------------------------------------------
> Comparte tu Facebook con tus amigos de Messenger ¡Descubre cómo! 
> <http://www.vivelive.com/feedfacebook/>
> ------------------------------------------------------------------------
> ¿Quieres los nuevos emoticonos en 3D? ¡Descárgatelos gratis! 
> <http://www.vivelive.com/emoticonos3d/index2.html>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>   

[SQLObject] FW: Newbie Problems connecting sqlite

[Joaquin A. M. <gat...@ho...>]

Hi,

I am probably doing something very wrong, but I can not discover what it 
is.
I googled and checked the archives but I did not found any hint.
I am new to SQLObject (although experienced in python and databases).
I was trying to follow the examples in the documentation but when executing 
the following code, identical to the one in the examples (except for the name of the database):

*********************************
from sqlobject import *
import os

db_filename = os.path.abspath('data_2.db')
if os.path.exists(db_filename):
    os.unlink(db_filename)

connection_string = 'sqlite:' + db_filename
connection = connectionForURI(connection_string)
sqlhub.processConnection = connection

class Person(SQLObject):
    name = StringCol()

Person.createTable()
**********************************************************

I get : "AssertionError: URIs must start with scheme:/ -- you did not 
include a / (in 'C:\\Python25\\programas\\ignasi_06\\data_2.db')"

Then I used "connection_string = 'sqlite:/' + db_filename" or"connection_string = 'sqlite:///' + db_filename"

but I got in both cases: "sqlite3.OperationalError: unable to open database 
file"

I tried several ways but neither run. Please help, and be nice if i am 
missing something obvious (as I suspect)
In running the new SQLObject 0.11.0 with python 2.5.4 in windows 
XP.

Thanks

Joaquin



Comparte tu Facebook con tus amigos de Messenger  ¡Descubre cómo!
_________________________________________________________________
¿Quieres los nuevos emoticonos en 3D? ¡Descárgatelos gratis!
http://www.vivelive.com/emoticonos3d/index2.html

Re: [SQLObject] foreignkey constraint not set (Firebird)

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

On Sat, Aug 22, 2009 at 09:19:59PM +0400, Oleg Broytmann wrote:
> On Sat, Aug 22, 2009 at 06:55:30PM +0200, Petr Jake?? wrote:
> > I am just wondering why the foreignkey constraint is not created
> 
>    Because SQLObject hasn't got an FK implementation for Firebird. FOREIGN
> KEYs require different dialects. See col.py, class SOForeignKey. Add a
> method _firebirdType().

   Oops, no. First, add necessary call in
FirebirdConnection.createReferenceConstraint(), then
SOForeignKey.firebirdCreateReferenceConstraint().

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

Re: [SQLObject] foreignkey constraint not set (Firebird)

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

On Sat, Aug 22, 2009 at 06:55:30PM +0200, Petr Jake?? wrote:
> I am just wondering why the foreignkey constraint is not created

   Because SQLObject hasn't got an FK implementation for Firebird. FOREIGN
KEYs require different dialects. See col.py, class SOForeignKey. Add a
method _firebirdType().

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

[SQLObject] foreignkey constraint not set (Firebird)

[Petr J. <pet...@tp...>]

Hi,
I am trying to follow the Person/Address foreignkey example in the
http://www.sqlobject.org/SQLObject.html#foreignkey

I am just wondering why the foreignkey constraint is not created on the
Address table. The column person_id is created of course, but the foreignkey
constraint is NOT set (I am checking this using IBExpert tools). Is this
intentional?

BTW I have found two problems (errors??):
1)
when: person = ForeignKey('Person', cascade = 'null')

than, when I am trying to delete rows from the Person table (see example
bellow), I am getting this error:

ProgrammingError
"(-104, 'isc_dsql_prepare: \n Dynamic SQL Error\n SQL error code = -104\n
Token unknown - line 1, column 33\n NULL')"
File:
/usr/lib/python2.5/site-packages/SQLObject-0.10.1-py2.5.egg/sqlobject/dbconnection.py,
line: 329

2)
when:     addresses = SingleJoin('Address')
print p1.addresses throws following:

unhandled AttributeError
"class FirebirdConnection has no attribute 'limit_re'"
File:
/usr/lib/python2.5/site-packages/SQLObject-0.10.1-py2.5.egg/sqlobject/firebird/firebirdconnection.py,
line: 120

I am on the Firebird 2.0 Database, Python 2.5.4,

=========== exampel code ==================
class Person(SQLObject):
    firstName = StringCol()
    middleInitial = StringCol(length=1, default=None)
    lastName = StringCol()
    addresses = MultipleJoin('Address')
#    addresses = MultipleJoin('Address', joinColumn="person_id")
#    addresses = SingleJoin('Address')

class Address(SQLObject):
    street = StringCol()
    city = StringCol()
    state = StringCol(length=2)
    zip = StringCol(length=9)
#    person = ForeignKey('Person', cascade = False)
#    person = ForeignKey('Person', cascade = True)
    person = ForeignKey('Person', cascade = 'null')

Person.dropTable(ifExists=True)
Address.dropTable(ifExists=True)
Person.createTable()
Address.createTable()

p1=Person(firstName="John", lastName="Doe")

Address(street='123 W Main St', city='Smallsville', state='MMM',
zip='65555', person=p1)
Address(street='321 V Side St', city='Bigsville', state='NNN', zip='54444',
person=p1)

print p1.addresses
peeps = Person.select()
for peep in peeps:
    print peep
    peep.destroySelf()

Re: [SQLObject] Precedence of manually installed pysqlite

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

On Thu, Nov 27, 2008 at 11:07:31PM +0100, Markus Gritsch wrote:
> On Thu, Nov 27, 2008 at 10:09 PM, Dan Pascu <da...@ag...> wrote:
> > On Thursday 27 November 2008, Oleg Broytmann wrote:
> >> > Or maybe some parameter to the dburi (like backend) would be simpler
> >> > and cleaner.
> >>
> >>    Either sqlite2://, sqlite3:// - or sqlite://...?backend=sqlite2.
> >
> > My preference would be towards the last example using a backend parameter
> 
> Me too.  Using 'sqlite2' as name is IMO not correct.  'pysqlite2'
> would be more appropriate but this makes it look weird at the URI
> beginning.  Appending ?backend=sqlite3 or ?backend=pysqlite2 looks
> nice.

   I did the first step to implement this - removed global variables;
imported DB API driver stored as self.module. I hope to implement backend
selection next week.

> > Also the backend arg should be just a preference, which should override
> > the default choice of the most recent backend as is done now.
> 
> Currently the precedence is
> 1. sqlite3
> 2. pysqlite2
> 3. sqlite
> 
> Since sqlite3 is bundled with Python, it get's outdated by more recent
> versions of pysqlite2 quite quickly.  So if it is desired to have as
> default the most recent version, the default order if no parameter is
> specified should be
> 
> 1. pysqlite2
> 2. sqlite3
> 3. sqlite

   This was changed in 0.11.

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

Re: [SQLObject] Which version am I using?

[Aaron R. <aar...@mo...>]

wow, that's terrific - thanks very much for your help!

On Fri, Aug 21, 2009 at 10:13 PM, Oleg Broytmann <ph...@ph...> wrote:

> On Fri, Aug 21, 2009 at 11:00:39AM +0200, Simon Cross wrote:
> > On Fri, Aug 21, 2009 at 10:35 AM, Aaron
> > Robinson<aar...@mo...> wrote:
> > > Thanks for the idea,.. sadly this version doesn't define __doc__ either
> :-(
> >
> > I think that puts you at version <= 0.6 since all branches after that
> > have the docstring [1, 2].
> >
> > If your package is called "SQLObject" and not "sqlobject" then you're
> > at version <= 0.5 [3].
> >
> > [1]
> http://svn.colorstudy.com/SQLObject/branches/0.6/sqlobject/__init__.py
> > [2]
> http://svn.colorstudy.com/SQLObject/branches/0.7/sqlobject/__init__.py
> > [3] http://svn.colorstudy.com/SQLObject/branches/0.5/
> >
> > Schiavo
> > Simon
>
>    Simon, thank you for the help!
>
> Oleg.
> --
>     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
>           Programmers don't die, they just GOSUB without RETURN.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

Re: [SQLObject] Which version am I using?

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

On Fri, Aug 21, 2009 at 11:00:39AM +0200, Simon Cross wrote:
> On Fri, Aug 21, 2009 at 10:35 AM, Aaron
> Robinson<aar...@mo...> wrote:
> > Thanks for the idea,.. sadly this version doesn't define __doc__ either :-(
> 
> I think that puts you at version <= 0.6 since all branches after that
> have the docstring [1, 2].
> 
> If your package is called "SQLObject" and not "sqlobject" then you're
> at version <= 0.5 [3].
> 
> [1] http://svn.colorstudy.com/SQLObject/branches/0.6/sqlobject/__init__.py
> [2] http://svn.colorstudy.com/SQLObject/branches/0.7/sqlobject/__init__.py
> [3] http://svn.colorstudy.com/SQLObject/branches/0.5/
> 
> Schiavo
> Simon

   Simon, thank you for the help!

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

Re: [SQLObject] Which version am I using?

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

On Fri, Aug 21, 2009 at 08:35:55PM +1200, Aaron Robinson wrote:
> Thanks for the idea,.. sadly this version doesn't define __doc__ either :-(

   That's a really really old version. sqlobject.__doc__ was added at
version 0.7 in 2005!

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

Re: [SQLObject] Which version am I using?

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

On Fri, Aug 21, 2009 at 08:41:17AM +0200, Simon Cross wrote:
> On Fri, Aug 21, 2009 at 1:18 AM, Aaron
> Robinson<aar...@mo...> wrote:
> > As SQLObject doesn't appear to define a
> > "__version__", how does one tell which version one is using??
> 
> Maybe try looking at the built-in documentation? The docstring for the
> module contains the version number (at least in version 0.10.2).
> 
> Something like:
> 
>    pydoc sqlobject
> 
> or
> 
>    python -c "import sqlobject; print sqlobject.__doc__"
> 
> should display it for you.

   sqlobject.__doc__ can even be used programmatically.

   Adding a kind of __version__ is in my TODO, not at the very top, but is
planned for near future, probably for the next major release.

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

Re: [SQLObject] Which version am I using?

[Simon C. <hod...@gm...>]

On Fri, Aug 21, 2009 at 10:35 AM, Aaron
Robinson<aar...@mo...> wrote:
> Thanks for the idea,.. sadly this version doesn't define __doc__ either :-(

I think that puts you at version <= 0.6 since all branches after that
have the docstring [1, 2].

If your package is called "SQLObject" and not "sqlobject" then you're
at version <= 0.5 [3].

[1] http://svn.colorstudy.com/SQLObject/branches/0.6/sqlobject/__init__.py
[2] http://svn.colorstudy.com/SQLObject/branches/0.7/sqlobject/__init__.py
[3] http://svn.colorstudy.com/SQLObject/branches/0.5/

Schiavo
Simon