sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Hello and Connections (to start)

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

I'm not going to get too stressed out about a single unused dictionary
and threading lock per application :)  Per SQLObject instance, that
would be a problem.

On Wed, 2003-03-12 at 21:47, Luke Opperman wrote:
> There was a semi-decent reason conscious decision not to call parent's init:
> It's in the parent's init that the pooling info is created. But I suppose that's
> a smaller price to pay than having things break in the future. I guess my only
> other thing is that if you agree this is about the way to do this sort of
> override, that DBAPI's __init__ should be careful about creating too much
> overhead. :)
> 
> - Luke
> 
> Quoting Ian Bicking <ia...@co...>:
> 
> > This looks like the right way to go about this.  You should call the
> > parent __init__, though.  More like:
> > 
> > def __init__(dsn, debug=0):
> >     PostgresConnection.__init__(dsn, debug=debug)
> > 
> > Though you don't *really* have to override __init__ at all, except if
> > you want to disallow non-applicable init arguments.
> > 
> >   Ian
> > 
> > 
> > 
> 
> 
> 

Re: [SQLObject] Hello and Connections (to start)

[Luke O. <lu...@me...>]

There was a semi-decent reason conscious decision not to call parent's init:
It's in the parent's init that the pooling info is created. But I suppose that's
a smaller price to pay than having things break in the future. I guess my only
other thing is that if you agree this is about the way to do this sort of
override, that DBAPI's __init__ should be careful about creating too much
overhead. :)

- Luke

Quoting Ian Bicking <ia...@co...>:

> This looks like the right way to go about this.  You should call the
> parent __init__, though.  More like:
> 
> def __init__(dsn, debug=0):
>     PostgresConnection.__init__(dsn, debug=debug)
> 
> Though you don't *really* have to override __init__ at all, except if
> you want to disallow non-applicable init arguments.
> 
>   Ian
> 
> 
> 

Re: [SQLObject] Hello and Connections (to start)

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

On Wed, 2003-03-12 at 01:17, Luke Opperman wrote:
> --------> local PostgresConnection.py code
> 
> from SQLObject import PostgresConnection as PC
> import psycopg
> from PoolStore import PoolStore
> import threading
> 
> _store = PoolStore(psycopg, maxPerDSN=10, total=65)
> 
> class PostgresConnection(PC):
>     
>     def __init__(self, dsn, debug=0):
>         self.dsn = dsn
>         self.debug = debug
>         self.instanceCache = {}
>         self.instanceCacheLock = threading.Lock()
>     
>     def getConnection(self):
>         return _store.getConnection(self.dsn)
>     
>     def releaseConnection(self,conn):
>         conn.close()
>     
>     def makeConnection(self):
>         pass

This looks like the right way to go about this.  You should call the
parent __init__, though.  More like:

def __init__(dsn, debug=0):
    PostgresConnection.__init__(dsn, debug=debug)

Though you don't *really* have to override __init__ at all, except if
you want to disallow non-applicable init arguments.

  Ian

Re: [SQLObject] Hello and Connections (to start)

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

On Wed, 2003-03-12 at 01:17, Luke Opperman wrote:
> Also, we've got a problem with Joins (possibly caching as well), where we can
> create an object, add it to another as a reference, but the objects are not
> equivalent (despite looking identical from repr). So we have (in effect):
> 
> >>> p = Person(1)
> >>> x = Phones.new(person=p...)
> >>> x
> <Phone 1 ....>
> >>> p.phones
> [<Phone 1 ....>]
> 
> but "x is p.phones[0]" and "x == p.phones[0]" are both false.

This is probably related to the caching problem that Frank had pointed
out before.  It should be fixed now in CVS.

  Ian

[SQLObject] alternateMethodName and creating SQL

[Luke O. <lu...@me...>]

Hello again -

Col.alternateMethodName: apparently not implemented yet? I assume the
implementation will look something like this (in the metaclass, while evaluating
each Column object: I added it around line 195 in SQLObject.py):

  # If the column defines an alternateMethodName for retrieval
  # apply it to the object.
  if column.alternateMethodName:
      fun = eval('lambda cls, val: cls.select(cls.q.%s == val)[0]' % column.name)
      dict[column.alternateMethodName] = classmethod(fun)

Of course, maybe part of the reason this hasn't been implemented yet is because
the semantics are more difficult that the implementation: What does the user
expect if there are really more than one returned by that query? What if there
are none? If alternateID is set in the Column, is it SQLObject's responsibility
to enforce uniqueness?

Thoughts? (I'm using the code above until future notice. :)

- Luke

P.S. alternateMethodName in Col() expects a function called "prefix(str,str)"? I
have no such function, so I ended up writing on that looks like:

def prefix(pref, post):
    return "%s%s%s" % (pref, post[0].capitalize(), post[1:])

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

[SQLObject] Hello and Connections (to start)

[Luke O. <lu...@me...>]

Ian, et al -

Hello! Well, I've been lurking using SQLObject since a long while ago, but only
really putting it into use in the last week or so. CVS from last week. Things
are mostly going great.

Ian, as you know, I talked about wanting to use our regular global database
connection pooling mechanism (which if you were watching the webware list a few
weeks ago, is a wrapper around a modified MiscUtils.DBPool, which expires unused
connections..). Anyways, I've created an ugly monster stepchild of your DBAPI
class, which takes the standard PostgresConnection and overrides certain parent
class methods. While it's not pretty, it works and is short. Code is below.

Also, I'll look more closely at this in the morning, but we're getting an odd
cache-related error. (which may indeed be due to our connection object? not 100%
sure on how the difference in instanceCaches plays out.)

If we create an object (Object.new(name=....)), it is persisted to the database
and everything works fine except it is not added to Object._SO_instanceCache.
However, if we get another reference (by Object(1), for instance), then it is
added to the cache. This comes into play, because if we ever have one that is
NOT in the cache, objInstance.destroy() raises an exception at line 720, as it
is attempted to be removed from the cache. (At a minimum we just need to check
if it is in cache before that del call, but I'd like to track down why it's not
caching in the first place.) The DELETE SQL works fine, so the object IS gone
regardless...

Also, we've got a problem with Joins (possibly caching as well), where we can
create an object, add it to another as a reference, but the objects are not
equivalent (despite looking identical from repr). So we have (in effect):

>>> p = Person(1)
>>> x = Phones.new(person=p...)
>>> x
<Phone 1 ....>
>>> p.phones
[<Phone 1 ....>]

but "x is p.phones[0]" and "x == p.phones[0]" are both false.

Again, I'll look into these in more depth in the morning, and this is using CVS
from a few days ago, but just curious if other people are seeing these? I
suppose the next thing I'll do is drop in the original PostgresConnection to
rule out my crazy code, but if that's the case I'll need some idea of how to
make mine work. :)

- Luke


--------> local PostgresConnection.py code

from SQLObject import PostgresConnection as PC
import psycopg
from PoolStore import PoolStore
import threading

_store = PoolStore(psycopg, maxPerDSN=10, total=65)

class PostgresConnection(PC):
    
    def __init__(self, dsn, debug=0):
        self.dsn = dsn
        self.debug = debug
        self.instanceCache = {}
        self.instanceCacheLock = threading.Lock()
    
    def getConnection(self):
        return _store.getConnection(self.dsn)
    
    def releaseConnection(self,conn):
        conn.close()
    
    def makeConnection(self):
        pass


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Re: [SQLObject] sqlite support without patch

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

On Tue, 2003-03-04 at 08:30, Frank Barknecht wrote:
> Did you forget the commit? At least I'm not seeing the sqlite-support
> in my last checkout. Or do I need to get a specific branch?

Sigh... yes I did.  I'll bang my head on the wall a few times, and maybe
next time I'll remember to commit.

  Ian

Re: [SQLObject] sqlite support without patch

[Frank B. <fb...@fo...>]

Hallo,
Ian Bicking hat gesagt: // Ian Bicking wrote:

> Cool -- I've added it to CVS in DBConnection.  I can't build the sqlite
> Python module, so I haven't tested it, but it looks straight-forward.

Ahm: Cool-- ;(

Did you forget the commit? At least I'm not seeing the sqlite-support
in my last checkout. Or do I need to get a specific branch?

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] sqlite support without patch

[Frank B. <fb...@fo...>]

Hallo,
Ian Bicking hat gesagt: // Ian Bicking wrote:

> Cool -- I've added it to CVS in DBConnection.  I can't build the sqlite
> Python module, so I haven't tested it, but it looks straight-forward.

Cool++.

Do you have an idea, why I'm always getting "p is not p2" in people.py
regardless of the backend I'm using? And is this important?

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] sqlite support without patch

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

Cool -- I've added it to CVS in DBConnection.  I can't build the sqlite
Python module, so I haven't tested it, but it looks straight-forward.

On Sun, 2003-03-02 at 04:50, Frank Barknecht wrote:
> Hallo,
> 
> I wasn't too happy with the need to patch SQLObject for sqlite
> support, and there was a small API-change regarding type information
> in pysqlite 0.4, while my patch still used 0.3. So I now made
> SQLiteConnection standalone as attached. The patching of SQLObject.py
> is gone, too. 
> 
> Also 'id' isn't hardcoded anymore, because I discovered pysqlite's
> DBAPI-extension "lastrowid".
> 
> I suspect, that SQLiteConnection now is really useable.  
> 
> ciao

Re: [SQLObject] Something 'funny' is happening while I unit test my code using sql object...

[Oisin M. <oi...@en...>]

Hi,

I'm using SQLObject-0.2. Does it work with the latest cvs update?

om


On Sunday, Mar 2, 2003, at 23:13 Europe/Dublin, Ian Bicking wrote:

> I tried it with CVS, but I can't figure out why it would do that.  Are
> you using SQLObject from CVS, or 0.2?
>
> On Sun, 2003-03-02 at 10:30, Oisin Mulvihill wrote:
>> Hi,
>>
>> I have found a very bizarre problem that is only affecting my unit 
>> test
>> and not the main program. However I believe this could be a more
>> general problem that may occur in other circumstances.
>>
>> I have modeled the behavior in a single python unit test file which
>> is attached to this file. I have tested this on two separate systems:
>>
>> Gentoo linux:
>> 	python2.2.2
>> 	mysql  Ver 11.18 Distrib 3.23.54, for pc-linux-gnu (i686)
>>
>> Mac osx 10.2:
>> 	python2.2.2
>> 	mysql  Ver 11.18 Distrib 3.23.52, for apple-darwin6.0 (powerpc)
>>
>> Each of these shows exactly the same problem when I run the test.
>>
>> If you run the test you should get the error:
>>
>> ===============================================================
>> FAIL: Test all of the basic operations the MachineStore provides.
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>    File "problem1.py", line 83, in test2
>>      self.assertEquals(machine['hostname'], "test1")
>>    File
>> "/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/
>> unittest.py", line 286, in failUnlessEqual
>>      raise self.failureException, \
>> AssertionError: 'bob' != 'test1'
>>
>> ----------------------------------------------------------------------
>> Ran 2 tests in 0.148s
>>
>> If you look at test2, in problem1.py, then you will see that somehow
>> the data I set in test1 is being returned in test2. This doesn't make
>> any sense as the tables and data have been destroyed and recreated,
>> before each test is run.
>>
>> I thought this might be a problem with caching so I disabled caching
>> in the machine object, using the documented "_cacheValue = False"
>> However this has made no difference.
>>
>> I'm at a loss as to how to proceed with this. My instincts tell me the
>> problem
>> isn't with MySQL, however I don't really know how to show that. 
>> Although
>> my main program isn't affected by this, I won't be able to trust sql
>> object
>> until I know why the above behavior is occurring. I'm hoping its some
>> error on my part that a fresh set of eyes will reveal.
>>
>> Can anyone help me with this or point me in the right direction? 
>> Thanks
>> in advance, all the best,
>>
>> om
>>
>

Re: [SQLObject] Something 'funny' is happening while I unit test my code using sql object...

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

I tried it with CVS, but I can't figure out why it would do that.  Are
you using SQLObject from CVS, or 0.2?

On Sun, 2003-03-02 at 10:30, Oisin Mulvihill wrote:
> Hi,
> 
> I have found a very bizarre problem that is only affecting my unit test
> and not the main program. However I believe this could be a more
> general problem that may occur in other circumstances.
> 
> I have modeled the behavior in a single python unit test file which
> is attached to this file. I have tested this on two separate systems:
> 
> Gentoo linux:
> 	python2.2.2
> 	mysql  Ver 11.18 Distrib 3.23.54, for pc-linux-gnu (i686)
> 
> Mac osx 10.2:
> 	python2.2.2
> 	mysql  Ver 11.18 Distrib 3.23.52, for apple-darwin6.0 (powerpc)
> 
> Each of these shows exactly the same problem when I run the test.
> 
> If you run the test you should get the error:
> 
> ===============================================================
> FAIL: Test all of the basic operations the MachineStore provides.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "problem1.py", line 83, in test2
>      self.assertEquals(machine['hostname'], "test1")
>    File  
> "/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/ 
> unittest.py", line 286, in failUnlessEqual
>      raise self.failureException, \
> AssertionError: 'bob' != 'test1'
> 
> ----------------------------------------------------------------------
> Ran 2 tests in 0.148s
> 
> If you look at test2, in problem1.py, then you will see that somehow
> the data I set in test1 is being returned in test2. This doesn't make
> any sense as the tables and data have been destroyed and recreated,
> before each test is run.
> 
> I thought this might be a problem with caching so I disabled caching
> in the machine object, using the documented "_cacheValue = False"
> However this has made no difference.
> 
> I'm at a loss as to how to proceed with this. My instincts tell me the  
> problem
> isn't with MySQL, however I don't really know how to show that. Although
> my main program isn't affected by this, I won't be able to trust sql  
> object
> until I know why the above behavior is occurring. I'm hoping its some
> error on my part that a fresh set of eyes will reveal.
> 
> Can anyone help me with this or point me in the right direction? Thanks
> in advance, all the best,
> 
> om
> 

[SQLObject] Something 'funny' is happening while I unit test my code using sql object...

[Oisin M. <oi...@en...>]

Hi,

I have found a very bizarre problem that is only affecting my unit test
and not the main program. However I believe this could be a more
general problem that may occur in other circumstances.

I have modeled the behavior in a single python unit test file which
is attached to this file. I have tested this on two separate systems:

Gentoo linux:
	python2.2.2
	mysql  Ver 11.18 Distrib 3.23.54, for pc-linux-gnu (i686)

Mac osx 10.2:
	python2.2.2
	mysql  Ver 11.18 Distrib 3.23.52, for apple-darwin6.0 (powerpc)

Each of these shows exactly the same problem when I run the test.

If you run the test you should get the error:

===============================================================
FAIL: Test all of the basic operations the MachineStore provides.
----------------------------------------------------------------------
Traceback (most recent call last):
   File "problem1.py", line 83, in test2
     self.assertEquals(machine['hostname'], "test1")
   File  
"/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/ 
unittest.py", line 286, in failUnlessEqual
     raise self.failureException, \
AssertionError: 'bob' != 'test1'

----------------------------------------------------------------------
Ran 2 tests in 0.148s

If you look at test2, in problem1.py, then you will see that somehow
the data I set in test1 is being returned in test2. This doesn't make
any sense as the tables and data have been destroyed and recreated,
before each test is run.

I thought this might be a problem with caching so I disabled caching
in the machine object, using the documented "_cacheValue = False"
However this has made no difference.

I'm at a loss as to how to proceed with this. My instincts tell me the  
problem
isn't with MySQL, however I don't really know how to show that. Although
my main program isn't affected by this, I won't be able to trust sql  
object
until I know why the above behavior is occurring. I'm hoping its some
error on my part that a fresh set of eyes will reveal.

Can anyone help me with this or point me in the right direction? Thanks
in advance, all the best,

om

[SQLObject] sqlite support without patch

[Frank B. <fb...@fo...>]

Hallo,

I wasn't too happy with the need to patch SQLObject for sqlite
support, and there was a small API-change regarding type information
in pysqlite 0.4, while my patch still used 0.3. So I now made
SQLiteConnection standalone as attached. The patching of SQLObject.py
is gone, too. 

Also 'id' isn't hardcoded anymore, because I discovered pysqlite's
DBAPI-extension "lastrowid".

I suspect, that SQLiteConnection now is really useable.  

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] more powerful joins on the fly...

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

On Sat, 2003-03-01 at 16:57, Oisin Mulvihill wrote:
> Hi,
> 
> I've really only started using MySQL in the past month. From the 
> beginning
> I've tried to use it through an ORM and SQLObject has proved to be the
> one I've had the most success with to date. I've successfully used it 
> in one
> project already and now I'm hoping to use it in another project.

Well, hey, except for me no one's used it very long...

> My new project however needs to be be able to do more powerful joins. I 
> would
> like to be able to create a single table by joining information from 
> other tables I have
> at 'run time'. I don't mean creating a class with a _join[] member, I 
> mean creating
> a join from a query. I am wondering if its possible to do this or how I 
> might be able
> to go about implementing this in SQLObject?

I'm not sure -- I haven't figured out how other kinds of joins would
really work in SQLObject.  Maybe you could give the schema and it will
be more clear from that...

  Ian

[SQLObject] more powerful joins on the fly...

[Oisin M. <oi...@en...>]

Hi,

I've really only started using MySQL in the past month. From the 
beginning
I've tried to use it through an ORM and SQLObject has proved to be the
one I've had the most success with to date. I've successfully used it 
in one
project already and now I'm hoping to use it in another project.

My new project however needs to be be able to do more powerful joins. I 
would
like to be able to create a single table by joining information from 
other tables I have
at 'run time'. I don't mean creating a class with a _join[] member, I 
mean creating
a join from a query. I am wondering if its possible to do this or how I 
might be able
to go about implementing this in SQLObject?

All the best,


om

[SQLObject] Re: [PATCH] experimental support for sqlite (with patch now!)

[Frank B. <fb...@fo...>]

Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:
> attached is a first try at adding support for sqlite [1]
> using PySQLite [2].

You know, on a german keyboard "a" for attach is right next to "y" for
send in Mutt.

Now I pressed "a"...

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

[SQLObject] [PATCH] experimental support for sqlite

[Frank B. <fb...@fo...>]

Hallo,

attached is a first try at adding support for sqlite [1]
using PySQLite [2].

It is not tested very much, only insofar that people.py runs without
errors. (Except "p is p2" which gives False here...)

Required changes are mostly in DBConnection.py, but also a tiny little
int() in SQLObject.py was needed because sqlite is typeless. 

[1] http://sqlite.org
[2] http://pysqlite.sourceforge.net

Have fun,
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] Several problems with current CVS

[Frank B. <fb...@fo...>]

Hallo,
Ian Bicking hat gesagt: // Ian Bicking wrote:

> Oops, I forgot to do cvs commit.  Check out a new version and try
> again...

Thanks. I still need to import everything from DBConnection by hand.
Then I'm coming through now, but still I get 

  >>> p2 = Person(p.id)
  >>> print p2
  <Person 2 firstName='John' middleInitial='Q' lastName='Doe'>
  >>> print p is p2
  0

which irritates me quite a bit. 

Later, it fails at 

>>> peeps2 = Person.select(AND(PhoneNumber.q.personID == Person.q.id, PhoneNumber.q.phoneNumber.startswith('612')))
Traceback (most recent call last):
  File "examples/people.py", line 196, in ?
    runTest(test3)
  File "examples/people.py", line 139, in runTest
    exec line[4:]
  File "<string>", line 1, in ?
NameError: name 'AND' is not define

but this is fixed by adding
  from SQLBuilder import *
in people.py

I don't know, what the importing policy in SO should be. I'd like it,
if "from SQLObject import * " would be sufficient to use SO.

And my Shop.py script using the records db, I wrote you about before
this list was started is working fine now as well.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] Several problems with current CVS

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

Oops, I forgot to do cvs commit.  Check out a new version and try
again...

On Sat, 2003-03-01 at 04:45, Frank Barknecht wrote:
> Hallo,
> 
> I'm still a bit struggling with getting SQLObject to work properly.
> I'm trying both postgres and mysql. 
> 
> First people.py aborted with an NameError: MySQLConnection not defined
> 
> from DBConnection import *
> 
> fixes this, but it's probably not intended this way, or is it? 
> 
> Then the tests seem to run, but not correctly. The first error, using
> either PG or MySQL is:
> 
>  >>> print p is p2
>  0
> 
> This should yield True or 1, I guess. 
> 
> The next error follows soon:
> 
>  >>> p.addRole(r)
>  Traceback (most recent call last):
>    File "people.py", line 182, in ?
>      runTest(test2)
>    File "people.py", line 136, in runTest
>      exec line[4:]
>    File "<string>", line 1, in ?
>  AttributeError: 'tuple' object has no attribute 'addRole'
> 
> Attached is the full debug output of a MySQL run. I'm running
> python2.2 here on Debian, with these db-packages:
> Source: python-mysqldb
> Version: 0.9.2-0.2
> Source: psycopg
> Version: 1.0.13-1
> 
> MySQL is 3.22, PG is 7.2.3.
> 
> Any ideas? 
> 
> I'd like to get this working properly before I'm going to debug my
> half functioning DBConnection.py with sqlite support ;)
> 
> ciao

[SQLObject] Several problems with current CVS

[Frank B. <fb...@fo...>]

Hallo,

I'm still a bit struggling with getting SQLObject to work properly.
I'm trying both postgres and mysql. 

First people.py aborted with an NameError: MySQLConnection not defined

from DBConnection import *

fixes this, but it's probably not intended this way, or is it? 

Then the tests seem to run, but not correctly. The first error, using
either PG or MySQL is:

 >>> print p is p2
 0

This should yield True or 1, I guess. 

The next error follows soon:

 >>> p.addRole(r)
 Traceback (most recent call last):
   File "people.py", line 182, in ?
     runTest(test2)
   File "people.py", line 136, in runTest
     exec line[4:]
   File "<string>", line 1, in ?
 AttributeError: 'tuple' object has no attribute 'addRole'

Attached is the full debug output of a MySQL run. I'm running
python2.2 here on Debian, with these db-packages:
Source: python-mysqldb
Version: 0.9.2-0.2
Source: psycopg
Version: 1.0.13-1

MySQL is 3.22, PG is 7.2.3.

Any ideas? 

I'd like to get this working properly before I'm going to debug my
half functioning DBConnection.py with sqlite support ;)

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] Name of 'id' field

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

New feature in CVS: add an attribute _idName that gives the id column's
name, like:

class MyTable(SQLObject):
    _idName = "SO_id"

On Fri, 2003-02-28 at 06:37, Frank Barknecht wrote:
> Hi,
> 
> this mail is to test the new list, but also to ask a real question:
> 
> I want to use SQLObject with a sql-table that already has a column called
> "id", which is not autoincrement. Now I could use SQLObject in read-only
> mode, which is okay, since I don't want to write currently. But in
> gerneral, I would like it if the id-table's name was configurable, like
>   
>   __id__ = 'SO_id'
> 
> In my special case, the data including "id" is regularly imported from
> another db (Filemaker on MacOS-9) via CSV into mysql ("import file").
> Updates should overwrite rows that are identified by "id".
> 
> ciao

[SQLObject] Name of 'id' field

[Frank B. <fb...@fo...>]

Hi,

this mail is to test the new list, but also to ask a real question:

I want to use SQLObject with a sql-table that already has a column called
"id", which is not autoincrement. Now I could use SQLObject in read-only
mode, which is okay, since I don't want to write currently. But in
gerneral, I would like it if the id-table's name was configurable, like
  
  __id__ = 'SO_id'

In my special case, the data including "id" is regularly imported from
another db (Filemaker on MacOS-9) via CSV into mysql ("import file").
Updates should overwrite rows that are identified by "id".

ciao
-- 
Frank Barknecht