[DB-SIG] Re: [Webware-discuss] [ANN] SQLObject 0.1

[Kevin Jacobs]

On 22 Oct 2002, Ian Bicking wrote:
> [...] And my vague impression is that PyDO avoids all this trouble by
> using the dictionary interface, so it doesn't have to create methods for
> each column -- I specifically didn't want to do something like that,
> because I don't want the database columns to be distinguishable from other
> methods and attributes.  Making that distinction, IMHO, is a significant
> compromise of the whole point of a middle object.

I agree, though in my mind there are some additional constraints.  First, it
is not desirable to pollute the namespace of your relational objects.  The
ideal would be that no "other methods or attributes" are visible in such an
object.  This does not imply that using a dictionary interface is a good
thing, though it does simplify the design.  Object-like interfaces feel more
natural, more Pythonic, and justify the extra effort to use an object
namespace.

Second, minimizing the overhead required to retrieve a column value is an
essential part of making an enterprise grade OR mapper.  Plus, it is also
desirable to encorce the data schema by disallowing the use of novel
attributes that will not be persistent.  The property and slots features
from Python 2.2+ provide both safety and performance.  There is an added
bonus that each object will not allocate a per-instance dictionary, which
makes a huge difference in the footprint and performance of applications
that can hold many thousands of row instances.

> MK does schema generation.  SQLObject deliberately does not; schema
> generation just didn't seem like a problem in need of solving to me.  I
> also want to make as few requirements on the schema as possible.

It is a problem, though thankfully an orthogonal one.  As are intelligent
type-mapping, constraint-checking layers, connection management, and SQL
dialect abstraction.  The real trick is to implement these all in a
weakly coupled component architecture, and yet have them all play nicely
together.

> Both MK and SQLObject currently only work with MySQL.  I hope to extend
> SQLObject, and I think it should be very easy (actually, I hope others
> will extend it, but I'll help them :).  There's really only one part of
> SQLObject that need to be ported -- inserting a row, to be specific.

I'm happy to help, though I suggest you take the first steps by creating a
backend abstraction layer.  Here are some things that such a layer would
handle:

  1) SQL literal representations and escaping (strings, identifiers, dates,
     timestamps, blobs, etc.)
  2) Inner/outer join syntax
  3) Query limits
  4) Last-insertion-id requests
  5) Large binary object interface

Best regards,
-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com