sqlobject-discuss

[SQLObject] longId=True handling...

[Sam's L. <sam...@gm...>]

I posted this on the TurboGears mailing list but now I'm posting it here in
hopes for more help.

Essentially I am upgrading from SQLObject 0.7.1dev_r1653 and MySQL 4.x
something to MySQL 5 something and SQLObject 0.10.6

I have this very complicated legacy TurboGears application that I'm
tasked with upgrading to 1.0.8 which has laid stagnant since the days
of early .99 series.

The original author used the following a lot in his table definitions:

class sqlmeta:
        style = MixedCaseStyle(longID=True)

What this means is that instead of the id column being named 'id' it
takes on the name of the table...so if the table is called EventQueue,
the id column name is EventQueueID.

So far so good....but here's where it gets weird.

It appears that under the really old versions of TurboGears one could
refer to this EventQueueID as just .id and everything would work the
way you want it to.  (This appears to only be done in the app under
kid templates).

But now, under TG 1.0.8/the latest version of SQLObject that doesn't work.
 Either I have to rename the
column to id or I have to refer to it as EventQueueID.

How can I make sqlObject seemlessly let me refer to columns named in
the long style just using id?

Thanks

Re: [SQLObject] longId=True handling...

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

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

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

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

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

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

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

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

Re: [SQLObject] longId=True handling...

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

On Wed, Jun 10, 2009 at 06:06:16PM -0700, Sam's Lists wrote:
> class sqlmeta:
>         style = MixedCaseStyle(longID=True)
> 
> It appears that under the really old versions of TurboGears one could
> refer to this EventQueueID as just .id and everything would work the
> way you want it to.  (This appears to only be done in the app under
> kid templates).
> 
> But now, under TG 1.0.8/the latest version of SQLObject that doesn't work.
>  Either I have to rename the
> column to id or I have to refer to it as EventQueueID.

   Well, you can always give the name of the column:

class MyTable(SQLObject):
   class sqlmeta:
      style = MixedCaseStyle(longID=True)
      idName = 'id' # or 'MyTableID' or whatever.

> How can I make sqlObject seemlessly let me refer to columns named in
> the long style just using id?

class Test(SQLObject):
    class sqlmeta:
        style = MixedCaseStyle(longID=True)

Test.createTable()

test = Test()
print test.id

   Output (SQLObject 0.10):

  1/Query   :  CREATE TABLE Test (
    id INTEGER PRIMARY KEY
)
 1/QueryR  :  CREATE TABLE Test (
    id INTEGER PRIMARY KEY
)
 1/Query   :  CREATE TABLE Test (
    id INTEGER PRIMARY KEY
)
 1/QueryR  :  CREATE TABLE Test (
    id INTEGER PRIMARY KEY
)
 2/QueryIns:  INSERT INTO Test VALUES (NULL)
 2/QueryR  :  INSERT INTO Test VALUES (NULL)
 3/QueryOne:  SELECT NULL FROM Test WHERE ((Test.id) = (1))
 3/QueryR  :  SELECT NULL FROM Test WHERE ((Test.id) = (1))
 1/Query   :  CREATE TABLE Test (
    id INTEGER PRIMARY KEY
)
 1/QueryR  :  CREATE TABLE Test (
    id INTEGER PRIMARY KEY
)
 2/QueryIns:  INSERT INTO Test VALUES (NULL)
 2/QueryR  :  INSERT INTO Test VALUES (NULL)
 3/QueryOne:  SELECT NULL FROM Test WHERE ((Test.id) = (1))
 3/QueryR  :  SELECT NULL FROM Test WHERE ((Test.id) = (1))

   No problem so far - id is id, not TestId. What am I doing wrong?

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