sqlobject-discuss — All things SQLObject-related

[SQLObject] Patch for create new row in Firebird database

[Predrag P. <pe...@cg...>]

when you try to insert new row in firebrid database using svn 210 you get:
------------------------------
 File "sqlobject\firebird\firebirdconnection.py", line 59, in 
_runWithConnection
    val = meth(conn, *args)
TypeError: _queryInsertID() takes exactly 7 arguments (6 given)
------------------------------

solution is to change 82 line from file 
"sqlobject\firebird\firebirdconnection.py"
old bad  line is:
------------------------------
    def _queryInsertID(self, conn, table, idName, id, names, values):
------------------------------

new 82 line look like:       
------------------------------
    def _queryInsertID(self, conn, soInstance, id, names, values):
------------------------------

and svn repository don't work again,

By

Re: [SQLObject] beginers question about geting columns names and litle more

[Predrag P. <pe...@cg...>]

Ian Bicking wrote:

> Predrag Peranovic wrote:
>
>> 1.     How to get columns name, format , size and rest of attributes
>> (like text size, notNull) from an SQLObject?
>
>
> Right now SomeSQLObject._SO_columnDict will give you the Col objects 
> (keyed by attribute name).  In the future, I hope to change all the 
> columns to be descriptors, so when you do SomeSQLObject.columnName you 
> will get the Col object, and it will have a clear interface for 
> introspection.  But until then you'll have to track changes, as 
> there's no stable interface for this yet.

Ok, thanks

>> 2.    How to set additional parameters to Firebird connection, like:
>> charset, role, dialect?
>
>
> I've applied these changes to the repository.
>
> Generally, you can still get to the connection via 
> sqlobject.firebird.FirebirdConnection.  Maybe there should be an 
> easier way.  You can also use the URI form.
>
> Any query parameters you use will be passed through as keyword 
> arguments, though right now only as strings.  At some point we might 
> need to do some translation to different types.  Hmm... is dialect 
> always an integer?
>
> Anyway, you should be able to do 
> firebird://user:password@host/dbname?charset=ISO-8859&role=admin (or 
> however those are supposed to be formatted).

Dialect is always integer, but to be honest it's parameter is important 
only if you want to connect to some very old database, and it can wait.

Connecting working fine with conncectForURI and with 
sqlobject.firebird.FirebirdConnection.

Thanks,
Predrag Peranovic

[SQLObject] Re: ideas about transactions and cache

[Cyril E. <cy...@de...>]

Ian Bicking wrote:
> Cyril Elkaim wrote:
> 
>> Use a _common_ cache and remove the DBMS pool from the dbconnection, 
>> each one connect to the DBMS once instanciated and maintains it opened 
>> during its lifetime. BTW, I think that it would be interesting to have 
>> only Transaction connections and let the user apply begin and commits 
>> when necessary. If necessary a client code can instanciate as many 
>> connections as necessary (as we already do). In this way every 
>> modification done by a connection will be reported back to the 
>> _common_ cache and  everybody will see the changes.
> 
> 
> I'm not sure I understand this completely.  But let's see...
> 
> First, what I believe to be the current behavior.
> 
> Anytime you commit a transaction, all the objects in the parent 
> transaction are expired.  Anytime you rollback all objects in the 
> transaction are expired.  This leaves out what I think you want: when 
> you commit, you want all objects in *other* transactions to expire.
> 

What's happen actually is, when you commit a rollback a transaction, 
it's _own_ cache is updated but _not_ the cache of its parent 
connection. If I've read the code correctly the parent's cache is never 
modified. A simple solution is, of course, to instanciate a Transaction 
object at the start of the application and never use its 'standard' 
parent connection. This is what we do and that works.

But if we want multiple users to make transactions it can't be used. The 
problem is that the DBMS must maintains the same connection during a 
transaction lifetime and the connection pool (that is now shared by all 
our sessions because we have now one Transaction) in dbConnection cannot 
guaranty that.

> Another way of thinking of it that I'd like, but may be hard to 
> implement, is a hierarchy of caches and connections.  When a transaction 
> is started, it has an empty cache.  On a fetch, it checks its parent's 
> cache, and if necessary adds to its parent's cache.  When it modifies 
> the object, it writes to its personal cache.  When it rolls back, it 
> deletes from its personal cache.  When it commits, it writes its 
> personal cache to its parent's cache.
> 

Seems to be a good concept and what i am beginning to work on.

Just a question, why is it necessary to have a separate Transaction 
class? Shouldn't be possible to have only the dbConnection and use it in 
Transactionnal mode if we want for example?

> Though the objects being cached couldn't be SQLObject instances, they'd 
> have to be record sets.  Each transaction would still have its own 
> instance.
> 
> Would that fit what you are thinking of?  A more expedient solution 
> would be for transaction commits to expire objects in other 
> transactions.  Well, with a bit of care, but something like that.
> 

Yes. but we must now have a ConnectionSet, or something like that, and 
create new dbConnection objects through this object, just an idea.


Cyril Elkaim

Re: [SQLObject] Re: Problems with validators and connectionFromURI

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

Cyril Elkaim wrote:
> That changes everything :-)
> 
> if fact in your code you assign to value and put back this _modified_ 
> value in the object, with the correction the value in memory is never 
> changed. I repeat it's simply what you are doing in the SO_setValue 
> method, I think that you just forgot to do that.
> 
> the difference are the first two letters in 'dbValue' :-)

Oh, wait, now I see it.  It's only an important change because of the 
line *right after* the line you change.  OK, applied.

[SQLObject] Re: Problems with validators and connectionFromURI

[Cyril E. <cy...@de...>]

That changes everything :-)

if fact in your code you assign to value and put back this _modified_ 
value in the object, with the correction the value in memory is never 
changed. I repeat it's simply what you are doing in the SO_setValue 
method, I think that you just forgot to do that.

the difference are the first two letters in 'dbValue' :-)

Cyril Elkaim


Ian Bicking wrote:
> Cyril Elkaim wrote:
> 
>> --- /home/cyril/src/SQLObject/sqlobject/main.py Tue Aug 31 10:49:27 2004
>> +++ main.py     Thu Sep  2 18:26:55 2004
>> @@ -760,10 +760,14 @@
>>              for name, value in kw.items():
>>                  fromPython = getattr(self, '_SO_fromPython_%s' % 
>> name, None)
>>                  if fromPython:
>> -                    value = fromPython(value, self._SO_validatorState)
>> -                toUpdate[name] = value
>> +                   dbValue = fromPython(value, self._SO_validatorState)
>> +                else:
>> +                    dbValue = value
>> +
>> +                toUpdate[name] = dbValue
> 
> 
> I don't see how this code changes anything...?
> 

Re: [SQLObject] ideas about transactions and cache

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

Cyril Elkaim wrote:
> Use a _common_ cache and remove the DBMS pool from the dbconnection, 
> each one connect to the DBMS once instanciated and maintains it opened 
> during its lifetime. BTW, I think that it would be interesting to have 
> only Transaction connections and let the user apply begin and commits 
> when necessary. If necessary a client code can instanciate as many 
> connections as necessary (as we already do). In this way every 
> modification done by a connection will be reported back to the _common_ 
> cache and  everybody will see the changes.

I'm not sure I understand this completely.  But let's see...

First, what I believe to be the current behavior.

Anytime you commit a transaction, all the objects in the parent 
transaction are expired.  Anytime you rollback all objects in the 
transaction are expired.  This leaves out what I think you want: when 
you commit, you want all objects in *other* transactions to expire.

Another way of thinking of it that I'd like, but may be hard to 
implement, is a hierarchy of caches and connections.  When a transaction 
is started, it has an empty cache.  On a fetch, it checks its parent's 
cache, and if necessary adds to its parent's cache.  When it modifies 
the object, it writes to its personal cache.  When it rolls back, it 
deletes from its personal cache.  When it commits, it writes its 
personal cache to its parent's cache.

Though the objects being cached couldn't be SQLObject instances, they'd 
have to be record sets.  Each transaction would still have its own instance.

Would that fit what you are thinking of?  A more expedient solution 
would be for transaction commits to expire objects in other 
transactions.  Well, with a bit of care, but something like that.

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

Re: [SQLObject] beginers question about geting columns names and litle more

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

Predrag Peranovic wrote:
> Hi,
> 
> I'm trying to use Python + SQLObject to develop some simple DB
> application for my use.
> 
> I'm pretty new in python and in the SQLObject and think that this is
> trivial question but I don't know how to solve it. So please help.
> 
> 
> 1.     How to get columns name, format , size and rest of attributes
> (like text size, notNull) from an SQLObject?
> 
> In version 0.5.2 I use:
> s = SomeSQLObject.select()[0]
> columnName = s._columns[0].kw['name']
> how can I  do something like this in 210 version from svn (is this some
> regular way to get that information)

Right now SomeSQLObject._SO_columnDict will give you the Col objects 
(keyed by attribute name).  In the future, I hope to change all the 
columns to be descriptors, so when you do SomeSQLObject.columnName you 
will get the Col object, and it will have a clear interface for 
introspection.  But until then you'll have to track changes, as there's 
no stable interface for this yet.

> 2.    How to set additional parameters to Firebird connection, like:
> charset, role, dialect?

I've applied these changes to the repository.

Generally, you can still get to the connection via 
sqlobject.firebird.FirebirdConnection.  Maybe there should be an easier 
way.  You can also use the URI form.

Any query parameters you use will be passed through as keyword 
arguments, though right now only as strings.  At some point we might 
need to do some translation to different types.  Hmm... is dialect 
always an integer?

Anyway, you should be able to do 
firebird://user:password@host/dbname?charset=ISO-8859&role=admin (or 
however those are supposed to be formatted).

> In 0.5.2,  I modified methods:
> ------------------------------------------------------------------
> class FirebirdConnection(DBAPI):
>    def __init__(self, host, db, user='sysdba',
>                 passwd='masterkey', autoCommit=1,
> +               #insert by me
> +                role=None, charset=None, dialect=0,
> +               #end of insert
>                 **kw):
> ...
> +           #insert by me to support additional option of firebird database
> +           self.dialect = dialect
> +           self.charset = charset
> +           self.role = role
> +           #end of insert
> 
>    def makeConnection(self):
>        #Modified by me to add support for charset, role and dialect
>        return kinterbasdb.connect(
>            host = self.host, database = self.db,
>            user = self.user, password = self.passwd,
> +           role = self.role, charset = self.charset,
> +           dialect = self.dialect
>            )
> ------------------------------------------------------------------
> end get what I need. But now it's look that FirebirdConnection method is
> deprecated.
> Do you have plans to insert this connection options in some future
> release, and how do you think to do that?
> And  how  do you  suggest to modify 210 version from svn to get features
> that I need.
> 
> I'm just want to know that to be easy to me to migrate on new version of
> SQLObject.


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

Re: [SQLObject] patch for joinMethodName argument problem

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

Applied.

Cyril Elkaim wrote:
> Ian,
> 
> The SVN 210 version has a bug that forbidden the use of joinMethodName, 
> here is a patch that should correct that problem:
> 
> --- joins.py    Thu Jul 29 10:24:49 2004
> +++ /usr/lib/python2.2/site-packages/sqlobject/joins.py Wed Sep  1 
> 15:54:33 2004
> @@ -27,6 +27,10 @@
>          return self._joinMethodName
> 
>      def withClass(self, soClass):
> +        if self.kw.has_key('joinMethodName'):
> +            self._joinMethodName = self.kw['joinMethodName']
> +            del self.kw['joinMethodName']
> +
>          return self.baseClass(soClass=soClass,
>                                joinMethodName=self._joinMethodName,
>                                **self.kw)

Re: [SQLObject] Re: Problems with validators and connectionFromURI

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

Cyril Elkaim wrote:
> --- /home/cyril/src/SQLObject/sqlobject/main.py Tue Aug 31 10:49:27 2004
> +++ main.py     Thu Sep  2 18:26:55 2004
> @@ -760,10 +760,14 @@
>              for name, value in kw.items():
>                  fromPython = getattr(self, '_SO_fromPython_%s' % name, 
> None)
>                  if fromPython:
> -                    value = fromPython(value, self._SO_validatorState)
> -                toUpdate[name] = value
> +                   dbValue = fromPython(value, self._SO_validatorState)
> +                else:
> +                    dbValue = value
> +
> +                toUpdate[name] = dbValue

I don't see how this code changes anything...?

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

[SQLObject] ideas about transactions and cache

[Cyril E. <cy...@de...>]

Hello,

We are now using sqlobject heavily in our application and everything 
works very well... well almost :-) Our biggest concern is about 
transactions. We can't use them and they are necessary, at least in our 
own case.

The problem is two sided, it's at the same time a DBMS connection pool 
problem and a (in fact lack of) shared cache problem.

I'll try to explain.

Our application server use one SQLObject connection by client connection 
(a session), this works and permit to use transactions beacause this way 
you have only one DBMS connection in the pool of each SLQLO dbconnection 
and don't risk to use the two different ones between the begin and the 
commit.

But the cache problem appears because if one client do a transaction in 
some objects and other clients already have these objects in their 
respective caches they won't see the modifications. Well known problem, 
and ZODB/ZEO uses a synchronization mechanism, for example, to 
invalidate the caches.

Of course we could use only one transaction for all our sessions but the 
pool cannot warrant that a complete transaction will use the same DBMS 
connection during its lifetime.

A side problem BTW is if you use a classic connection for reading object 
from the database and then instanciate a transaction to write back your 
modifications the classic connection won't see these modifications. The 
reason is the transaction uses its own cache and do not modify the one 
of its parent connection.

Of course we can disable the cache alltogether but the performance is 
awful, in our case 6 to 10 times slower, clearly not usable.

A possible solution.

Use a _common_ cache and remove the DBMS pool from the dbconnection, 
each one connect to the DBMS once instanciated and maintains it opened 
during its lifetime. BTW, I think that it would be interesting to have 
only Transaction connections and let the user apply begin and commits 
when necessary. If necessary a client code can instanciate as many 
connections as necessary (as we already do). In this way every 
modification done by a connection will be reported back to the _common_ 
cache and  everybody will see the changes.

That will not correct the problem of having multiple instance of 
SQLObject in different machines but at least, I think that will permit 
to use transactions with the cache.

Any comments?


Thanks in advance
Cyril Elkaim

Re: [SQLObject] svn repository broken?

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

Tracy Ruggles wrote:
> Here's what I get when trying to checkout SQLObject:
> 
> tracyruggles$ svn co svn://colorstudy.com/trunk/SQLObject
> svn: Berkeley DB error while opening environment for filesystem /var/lib/subversion/repository/db:
> DB_RUNRECOVERY: Fatal error, run database recovery

It's the damn permissions.  Ever since I set up viewcvs it's been 
causing problems.  Viewcvs needs write permission (blech; bdb thing, I 
guess), and it runs as a different user from svnserver, and then it 
causes problems and I have to go in and fix permissions and do recovery. 
  Annoying, but now fixed.

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

[SQLObject] svn repository broken?

[Tracy R. <tr...@re...>]

Here's what I get when trying to checkout SQLObject:

tracyruggles$ svn co svn://colorstudy.com/trunk/SQLObject
svn: Berkeley DB error while opening environment for filesystem /var/lib/su=
bversion/repository/db:
DB_RUNRECOVERY: Fatal error, run database recovery

tracyruggles$ svnadmin recover .svn
Please wait; recovering the repository may take some time...
svn: Expected version '3' of repository; found version '4'


I've checked that the other subversion-based repositories that I have check=
ed out work correctly, and they do.  Is this something in SQLObject subvers=
ion repository?  (I apologize in advance if it's a subversion error on my s=
ide...)

Thanks,
Tracy

I'm using the svn client version 1.0.0 on MacOS X.

[SQLObject] select distinct patch

[Marcin W. <wo...@un...>]

Hi,
I applied the distinct-select.patch from Jeremy Fitzhardinge
http://article.gmane.org/gmane.comp.python.sqlobject/1637
and it works as expected.
I tested it with MySQL.
The patch is very useful for me -- it would be nice to have it in 0.6.

Marcin

--=20
Marcin Wojdyr  |  http://www.unipress.waw.pl/~wojdyr

[SQLObject] beginers question about geting columns names and litle more

[Predrag P. <pe...@cg...>]

Hi,

I'm trying to use Python + SQLObject to develop some simple DB
application for my use.

I'm pretty new in python and in the SQLObject and think that this is
trivial question but I don't know how to solve it. So please help.


1.     How to get columns name, format , size and rest of attributes
(like text size, notNull) from an SQLObject?

In version 0.5.2 I use:
s = SomeSQLObject.select()[0]
columnName = s._columns[0].kw['name']
how can I  do something like this in 210 version from svn (is this some
regular way to get that information)

2.    How to set additional parameters to Firebird connection, like:
charset, role, dialect?

In 0.5.2,  I modified methods:
------------------------------------------------------------------
class FirebirdConnection(DBAPI):
    def __init__(self, host, db, user='sysdba',
                 passwd='masterkey', autoCommit=1,
+               #insert by me
+                role=None, charset=None, dialect=0,
+               #end of insert
                 **kw):
...
+           #insert by me to support additional option of firebird database
+           self.dialect = dialect
+           self.charset = charset
+           self.role = role
+           #end of insert

    def makeConnection(self):
        #Modified by me to add support for charset, role and dialect
        return kinterbasdb.connect(
            host = self.host, database = self.db,
            user = self.user, password = self.passwd,
+           role = self.role, charset = self.charset,
+           dialect = self.dialect
            )
------------------------------------------------------------------
end get what I need. But now it's look that FirebirdConnection method is
deprecated.
Do you have plans to insert this connection options in some future
release, and how do you think to do that?
And  how  do you  suggest to modify 210 version from svn to get features
that I need.

I'm just want to know that to be easy to me to migrate on new version of
SQLObject.


Thanks in advance, and sorry for my bad English

Predrag Peranovic

[SQLObject] Re: Problems with validators and connectionFromURI

[Cyril E. <cy...@de...>]

Hello,

here is a patch that should correct the problem with validators. In fact 
  the method _SO_setValues does the job correctly so I just copy its 
code to set():




--- /home/cyril/src/SQLObject/sqlobject/main.py Tue Aug 31 10:49:27 2004
+++ main.py     Thu Sep  2 18:26:55 2004
@@ -760,10 +760,14 @@
              for name, value in kw.items():
                  fromPython = getattr(self, '_SO_fromPython_%s' % name, 
None)
                  if fromPython:
-                    value = fromPython(value, self._SO_validatorState)
-                toUpdate[name] = value
+                   dbValue = fromPython(value, self._SO_validatorState)
+                else:
+                    dbValue = value
+
+                toUpdate[name] = dbValue
                  if self._cacheValues:
-                    setattr(self, instanceName(name), value)
+                   setattr(self, instanceName(name), value)
+
              for name, value in extra.items():
                  setattr(self, name, value)




Cyril Elkaim

Re: [SQLObject] connection document on wiki

[Michael W. <li...@mi...>]

> I think cache in "connection.cache.expireAll()" is actually a CacheSet
> object, and expireAll() is a method of CacheFactory.  That lead me to t=
ry
> the following:
>
> for key in connection.cache.caches.keys():
>      connection.cache.caches[key].expireAll()

Hmnn... that's almost exactly what I have done.

import gc
def expire_all():
    c =3D get_connection()
    for k in c.cache.caches.keys():
        c.cache.caches[k].expireAll()
    gc.collect()

Ah, thought this looked familiar:

"The SQLObject code has a bug in expireAll =96 ref(obj) instead of
ref(value) =96 and the method isn=92t called from anywhere in the code ei=
ther,
at least not in the svn checkout I am looking at."

http://mikewatkins.net/categories/technical/2004-07-14-1.html

[SQLObject] patch for joinMethodName argument problem

[Cyril E. <cy...@de...>]

Ian,

The SVN 210 version has a bug that forbidden the use of joinMethodName, 
here is a patch that should correct that problem:

--- joins.py    Thu Jul 29 10:24:49 2004
+++ /usr/lib/python2.2/site-packages/sqlobject/joins.py Wed Sep  1 
15:54:33 2004
@@ -27,6 +27,10 @@
          return self._joinMethodName

      def withClass(self, soClass):
+        if self.kw.has_key('joinMethodName'):
+            self._joinMethodName = self.kw['joinMethodName']
+            del self.kw['joinMethodName']
+
          return self.baseClass(soClass=soClass,
                                joinMethodName=self._joinMethodName,
                                **self.kw)


Hope that helps

Cyril Elkaim

Re: [SQLObject] connection document on wiki

[Charles B. <li...@st...>]

> > 1.  Is there a way to manually close a connection?
>
> Hmm... no.  And since SQLObject does pooling it's not trivial.

I'm more interested in removing and closing connection objects themselves
(i.e. all connections in a specific connection object's pool) vs a single
specific connection in a connection object's pool.   This would be
especially useful when the connection object is only passed into objects
when they are fetched (vs defined in the object definition).

When I use connection objects this way, they are effectively a pool of one
connection used for fetching/updating one object.  Granted this is not as
efficient as keeping a pool of connections (or a connection per thread) but
it is handy for a quick test or rare use situations.  (even then it is
impractical without a close function though).

I'm not sure if looking at this higher level would simplify the problem to a
more trival one. My work around is to re-use connections as intended. :)

> > 2.  Is there a way to manually expire the cache of a connection?
>
> connection.cache.expireAll() -- that won't removed the cached objects,
> but it will only hold weak references.

I think cache in "connection.cache.expireAll()" is actually a CacheSet
object, and expireAll() is a method of CacheFactory.  That lead me to try
the following:

for key in connection.cache.caches.keys():
     connection.cache.caches[key].expireAll()

but got:

  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site
-packages/SQLObject/Cache.py", line 151, in expireAll
    self.expiredCache[key] = ref(obj)
NameError: global name 'obj' is not defined

should obj in this case actually be value from the previous line of:
     for key, value in self.cache.items():
?

I can file a bug report if so.

In the mean time I'm giving the method posted by Eddie Corns in July a
closer look:
http://thread.gmane.org/gmane.comp.python.sqlobject/1630

> > On a more general note I'd be very interested to hear details on how
others
> > deal with connections in their SQLObject applications, especially
> > multi-process applications.
>
> Yes, that's still a bit of an open issue.  It's hard, because it really
> depends on how accurate you want to be -- you can be very accurate by
> checking each time an attribute is accessed, but that's really
> inefficient, and may give you an inconsistent view.  I'd be interested
> in hearing other people's thoughts as well.

My goal with these questions is to end up with an approach that caches
fetched data for a specific page request, and then flushes the cache at the
end of the request.  In practice this might not save much over checking the
database each time, but its the best compromise I've come up with so far.


Thanks Ian!

-Charles.

[SQLObject] Re: Problems with transactions

[Cyril E. <cy...@de...>]

Ian,

the set() method doesn't take Transaction in account if an object has 
been retrieved outside a Transaction. ie:

This works:
BEGIN
get_object
modify
set()
COMMIT/ROLLBACK

But this doesn't:
get_object
modify
BEGIN
set()
COMMIT/ROLLBACK

The reason is the _connection property is setted during object creation 
only. A simple solution is to add connection to the argument list of set 
(set(self, connection=None,**kw).

For the moment when I use a transaction I explicitly do:
  obj._connection = trans_connection

This way it works

BTW I think that I have found where the problem with the validators 
lies, i'm testing.

Regards
Cyril Elkaim

[SQLObject] Index patch

[Jeremy F. <je...@go...>]

Here's a rework of the patch I posted a few weeks ago.  It adds the
ability to create indexes along with the tables from within SQLObject.
To use it, you simply do something like:

class MyThing(SQLObject):
	thing = IntCol()
	other = IntCol()

	idx = Index(thing)
	idx2 = Index((thing, other), unique=True)


The implementation works for me, but there's a few warts in there.  The
big one is that the Index object refers to Col objects, but ultimately
needs to find the mapping to SO_Col objects to get the dbName for each
column.  For ForeignKey columns this is tricky, because they add the
'ID' to the end of the column name, but there doesn't seem to be a
record of the original name - I duplicate the code in _SO_ForeignKey
which does this, which isn't nice.

	J

[SQLObject] Re: object has no attribute

[Cyril E. <cy...@de...>]

Ian,

The joinMethodName argument doesn't work with MultipleJoin. If I write 
the following:

class Patient(SQLObject):
     teeth = MultipleJoin("Tooth", joinColumn="patientid", 
joinMethodName="teeth")

the svn verion complains because joinMethodName receives multiple 
values. In fact I must comment out the parameter setting in the 
following method from joins.py/Join to make it work.

     def withClass(self, soClass):
         return self.baseClass(soClass=soClass,
                               #CE joinMethodName=self._joinMethodName,
                               **self.kw)


But the better solution should be, I think, to not have to use 
joinMethodName at all, the property name does the trick for me. I think 
that it should be better to set addRemoveName instead; for example:

class Patient(SQLObject):
     teeth = MultipleJoin("Tooth", joinColumn="patientid", 
addRemoveName="Tooth")

   ==> defining  addTooth and removeTooth

Cyril Elkaim

[SQLObject] Re: object has no attribute

[Cyril E. <cy...@de...>]

Ian Bicking wrote:
> MJR wrote:
> 
>> Any idea why the one-to-many example from SQLObject documentation 
>> works with
>> addresses=MultipleJoin('Address'), but doesn't with
>> addr=MultipleJoin('Address').
> 
> 
> That seems to be a bug -- SQLObject simply ignores the attribute you 
> use.  Well, it's hard, because there's sometimes more than one method, 
> as in RelatedJoin (with add and remove).
> 

Yes,

I have the same problem with the svn version and take a look inside 
joins.py/SOMultipleJoin.__init__ method. I see that now you use the 
joinMethodName parameter to create the property name. I understand that 
but it is not very intuitive. Someone intends that the property name of 
created object is the one he writes in his code. Why not use this name 
for creating properties and methods ?

Cyril Elkaim

Re: [SQLObject] object has no attribute

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

MJR wrote:
> Any idea why the one-to-many example from SQLObject documentation works with
> addresses=MultipleJoin('Address'), but doesn't with
> addr=MultipleJoin('Address').

That seems to be a bug -- SQLObject simply ignores the attribute you 
use.  Well, it's hard, because there's sometimes more than one method, 
as in RelatedJoin (with add and remove).

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

Re: [SQLObject] Re: Problems with transactions

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

Cyril Elkaim wrote:
> I answer my own message,
> 
> I didn't understand that I must pass a transction object in lieu of the 
> connection object. That works this way. But I think there is a problem 
> yet with the pool of sql connections when doing multithreading. Not sure 
> that the same SQL connection is used twice by _runWithConnection during 
> a transaction implying multiple SQL statements. Any ideas?

It should be.  If you turn on debugging, you should see connection IDs, 
which should help you see what queries belong to the same transaction. 
I'm not entirely comfortable with how that all works, so there certainly 
may be bugs, but I've tried to make it work.

The Transaction object fiddles with the underlying connection, calling 
the connection's methods with the transaction object as "self".  This 
way it overrides some specific methods (those that get connections) even 
if they are called indirectly.

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

Re: [SQLObject] Problems with validators and connectionFromURI

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

Cyril Elkaim wrote:
> Hello,
> 
> We have found the following two problems:
> 
> If someone modify a property and then read it back the 'toPython' 
> validator's method is _not_ called. In our case we are using a 
> 'UnicaodeValidator' to store Unicode strings in UTF8 into a Postgres 
> database, code follows:
> 
> 
> class UnicodeValidator(sqlobject.include.validators.Validator):
> 
>     def toPython(self, value, state=None):
>         if value is None:
>             return None
> 
>         return unicode(value,"utf8")
> 
>     def fromPython(self, value, state=None):
>         if value is None:
>             return None
> 
>         return value.encode("utf8")

I think there's a shortcut, so if you assign an attribute it goes 
through fromPython to the database, but we keep the original value in an 
instance variable.  So when you later access the attribute, it's not 
toPython(fromPython(originalValue)), but just the original value.  This 
might be noticeable because validators normalize values.  Is this what 
you are encountering?  Is it causing a problem?

> Reading an object from the database from the first time correctly calls 
> the validator 'toPython' method , but not after a write. Is somebody 
> else having this problem? It arises even when disabling the cache. The 
> 'fromPython' method _seems_ to be called every time.
> 
> My second concern is with the parsing of the 'query' part in 
> connectionFromURI; the values are assigned to properties as String and 
> are not evaluated, for Boolean values (like enableing and disabling the 
> cache) it ask for problems as setting cache=False always make a True 
> value. A simple solution is to use eval before assigning the property 
> inside the code of the method, but it may raise security problems. Again 
> is somebody else having this problem?

Yeah, the query part isn't fully thought out.  It works for booleans, 
though -- the empty string is a false value, any non-empty string is 
true.  Some safe evaluator might be nice at some point, that knows how 
to parse integers and some booleans (true/false, yes/no, etc).

> If I do a patch what is the procedure to post it and make it reviewed?

I guess mail it to the list.  Bugs should go to the bug tracker on 
sf.net.  There's also a place for patches there, though I'm fine for a 
patch going to either location.

> All in all the library is quite impressive and I must thank the author 
> for his work.

Thanks.

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