Re: [SQLObject] Join tables

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

On Nov 10, 2003, at 3:02 PM, John Baker wrote:
> On Monday 10 November 2003 20:56, Ian Bicking wrote:
>
>> doesn't involve terms (or even concepts) like "implicit" or "folding",
>> then maybe I'll feel more enthusiastic.  I'm trying to avoid magic to
>> the degree possible, which is where my reluctance comes from.
>
> I didn't really find a real reason in there ;-)
>
> Superset mapping makes obvious logical sense when you present the 
> model to an
> OO programmer. If you are talking objects, you map with supersets. 
> Some of my
> code to cope with the above example is absolutely sick, but I have no 
> choice.
> However SQLObject is free, so I'm not going to worry too much - I'll 
> just
> implement it for you one day :-)

Sure.  But I'm more likely to commit it if it fits my sensibilities ;)  
But who knows, it all depends on what the implementation looks like.  
Actually, the description of the implementation will be of the greatest 
interest to me.  If you can concisely, unambiguously, and completely 
describe how to use it, including all the corner cases and likely 
gotchas, then I'll be convinced.  (Keeping in mind that for SQLObject a 
description of use has to include the Python interface, the SQL schema 
required, and the queries produced; and, as a tool, extension and 
customization have to be accounted for)  If the implementation is a 
mess, that can be fixed -- if the semantics are a mess you're stuck.

> Consider other cases where you have a collection of objects that you 
> want to
> map back to one parent, regardless if  you are actually mapping to a 
> child.
> You might have a "Property", and you might want any object to have a
> collection of Properties. In OO, you'd define something like:
>
> class Item (SQLObject):
> 	properties = MultipleJoin("Property")
> 	name = StringCol()
>
> class Bill (Item):
> 	value = FloatCol()
>
> .. and many other extension of Item
>
> and every extension has access to the list of Properties.

And this is just what makes me nervous.  What does the Item table look 
like?  How does it relate to the rest of the system, and how does it 
grow?  Presumably Bill and other classes are keyed off of item_id, but 
how do you know which kind of Item you are working with?

Superclasses shouldn't have to be aware of subclasses, but I don't see 
how that can happen with this system.  Also, you get all sorts of 
weirdness in class creation -- essentially Item.__new__ will have to 
return a Bill instance, or some other instance, depending on the ID.

What looks like inheritance isn't really inheritance, it's something 
else.  I don't know what to call it, but I don't want to create a false 
cognate by phrasing it incorrectly -- especially when its in relation 
to something with the complex semantics of a Python class.

> We define OO structures to reduce our code and reuse objects, and 
> mappings to
> tables should work in exactly the same way. After all, why should the 
> OO
> developer have to worry about tables? The OO developer wants to store
> something, he/she doesn't want to worry about how it's stored...

I can appreciate this sentiment, but I'm also wary of it.  There are 
other Python ORMs that do better at distinguishing between business 
logic and persistence logic, but SQLObject is coming from a bit 
different perspective -- it's mapping tables to Python objects, not 
mapping Python classes to tables.  Ultimately I am unconvinced that you 
can get the persistence for free, that you can map arbitrary Python 
onto a DBMS -- at least without making the DBMS pointless.  Now, that's 
not to say SQLObject won't move more towards being a "seamless" 
persistency for objects; I have several ideas that could help improve 
this.  But I don't even know what "seamless" really means in this 
context -- no seamless persistence *can* exist in Python, because the 
status-quo is non-persistence (which will continue to be a viable 
option for a large number of objects and situations).

But I'm wandering off onto tangents.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org