Re: [SQLObject] two beginner's questions

[Nick <ni...@dd...>]

On Mon, 2003-04-28 at 21:59, Luke Opperman wrote:
> care to give a quick overview of the additional things made available
> by late binding? If you're not dynamically altering the class based
> on sub/super attribs, and you're mapping to a somewhat normalized set
> of relations (as opposed to meta-tables of class/attributes or
> similar), I don't see the difference from an inheritance perspective
> at least.

The main problem is the complexity you introduce with new style
metaclassing using type as the super.  I believe it may be possible to
handle inheritance correctly, but as it is you can't really subclass a
class that inherits from SQLObject.  The way you defined my classes were
extremely similar-- you provide the class attributes table, key,
attributes, collections (_table, _idName, _columns, _joins).  attributes
was a dictionary rather than a list, with the keys being the attributes
and the values being an Attribute object, similar to Col.  I found
converting code from my classes to SQLObject extremely trivial, and in
some ways the resulting class definition was much simpler using
SQLObject.

However, my registration function only registered each class in a
dictionary for reference like SQLObject does, but that's it.  When you
called db the DB lookup methods (which I called new() for inserts,
getUnique() for unique lookups and getAggregate() to get a list of
objects matching a condition), the results of the queries were stored in
Value objects that track each attribute's value (and controlled type
normalization, update tracking, etc.).  When you tried to make a
property access, __getattr__ resolved the name according to the
aforementioned attributes dictionary, handling all the type checking
etc.

> Were there other benefits to the late-binding scheme? I'd say the one
> immediate advantage to the metaclass system is that it seems much
> easier to introspect on than __getattr__/__setattr__ systems I've
> seen in the past.

True; introspection is very limited using __getattr__ and __setattr__,
but then again, what kind of introspection are you looking for here, in
practical use.  Sure, you won't be able to do dir(class), but all that
information was available in other ways.  Maybe some examples?

> I suppose of immediate interest to this thread is how a late-binding
> system would make implementation-inheritance like the original poster
> was looking for possible.

Since all the lookups are done when attributes are accessed, it's
actually possible to alter the attributes dictionary (or any other class
property) at any time without having to rebind properties or methods. 
Subclassing becomes a non-issue since we only register the name of the
class to make sure it's unique.  This has the advantage of being able to
have class names that are identical get reside in different modules, by
the way.

>  It still needs to map to some set of
> tables, the easiest but of least interest to me for an ORM being the
> meta-table system.

Indeed; my model was very similar to SQLObject in many, many ways, and
worked almost identically from a practical standpoint.  Only the
internals and method names were different.  SQLObject does some things
nicer, but I think that's just having better ideas for how things should
be accessed than me rather than other limitations :)

I'm not sure if I'm really answering your questions though.

Nick