[orm-devel] Re: ORM mailing list inquiry...

[Charles Brandt]

Hi Diedrich,

Thanks for the quick response!

> I didn't know SQLObject was changed to use metaclasses. I didn't look
> at their stuff for quite a while. I was going to change orm to use
> metaclasses as well, but I'm not sure about it, yet.

I must admit that I haven't had a chance to learn metaclasses yet. From what
I've seen they look pretty slick, but they also seem to introduce a lot of
complexity and maintenance overhead that I'm not sure is worth it.  I think
they introduce limitations on classes and objects as far as the namespace
goes (required to be globally unique), and the whole initialization phase of
an object became very tricky.  This is probably what ultimately led to the
finicky connection issues I experienced. It ideally wanted the connection to
be specified in the class definition, vs passed in during object creation.
Since I plan to reuse a connection within a thread, defining the connection
at the class definition level is inconvenient.  I'd be interested to hear
your thoughts on the topic as you go down that path.  Ian (the author of
SQLObject) would also be a good one to talk to.   I don't feel like I've
done enough homework on the subject to discuss it intelligently. :)

> I've change the server's harddisk and it seems like it didn't copy all
> the files. I'll take a look at it later today.
yay! its back!  Have you considered subscribing the list to gmane.org?
(http://gmane.org/subscribe.php)  They make searching the archives fairly
easy.

#######################################
I came accross one extremely minor typo in dbclass.py, line 409:
return "<" + self.__class__.__name__ + " (" + \
        string.join(ret, " ") + ">"

is missing a closing paren:
return "<" + self.__class__.__name__ + " (" + \
        string.join(ret, " ") + ")>"

#######################################
I tried to check out the latest cvs source, but got the following response:
cvs -d :pserver:anonymous at cvs.tux4web.de:/var/data/public_cvs login
Logging in to :pserver:anonymous at cvs.tux4web.de:2401/var/data/public_cvs
CVS password:
cvs [login aborted]: unrecognized auth response from cvs.tux4web.de: Unknown
command: `pserve'

maybe a typo in the /etc/xinetd.d/pserver conf file?

#######################################
One feature that I'm thinking about adding is a count method to the
datasource.select.  (inspired by SQLObject...)  This would wrap the SQL
COUNT(*) statement and might be handy when doing selects in batches.  I was
using this as a low cost test for the existence of a specific column value,
but fetchall() should work fine in this case since there should only ever be
zero or one value.

#######################################
When testing if a fetchone() returned a value as follows:
item = conn.select(MapItems, dkey-"sam").fetchone()
if item:

I get:
  File
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site
-packages/orm/dbclass.py", line 299, in __getattr__
    if name[0] == "_": return self.__dict__[name]
KeyError: '__nonzero__'

It looks like __getattr__ is assuming that a attribute/column name is going
to be sent along.  Would it make sense to change name to a keyword argument
with a default value set to return the dbclass (or a copy)?

I suppose the easy answer to this is to just do a fetchall() and see if the
resulting list has items.

#######################################
> Documentation is behind... I know...:-(
I'll try to help out if I can... need to look into editing docbook formats.

I better go ahead and send this before it gets any longer.  :)  Thanks for
the help Diedrich.

-Charles.