[Zope-dev] Re: zope.sqlalchemy, integration ideas

[Martijn Faassen]

Brian Sutherland wrote:
[snip]
> This was a problem with sqlos containers as well. It gets nasty quickly.
> Say you have 2 containers, of people and addresses. Also people can have
> an address.
> 
> So you can get to an address in 2 different ways:
> 
>     /adresses/address1
>     /people/person1/address1
> 
> What should the url for address1 be? I'd vote for /adresses/address1.
> But due to the LocationProxy, you'll get different results for different
> IAbsoluteURL calls depending on how you traversed to the object.

I've seen this complaint coming from quite a few people a number of 
times, so this needs some thinking about.

One interesting observation is that if you do this in the ZODB you'd get 
the exact same problem, and then people use things like zc.shortcut to 
get around it. So, in the ZODB, we typically don't give the same object 
two URLs.

I guess one difference here is that it seems more common in the RDB 
scenario to have multiple ways to reach the same object, and even if you 
just publish one, you can get to the actual object in multiple ways.

In this case it'd be nice to convince IAbsoluteURL to somehow know which 
URL option is the best, or alternatively, give the object somehow its 
'canonical' location (parent, etc) even if you don't get it that way.

>> This is the "it should work like ZODB-backed objects" pattern I've been 
>> trying to follow as a design guideline. Since for contained objects I can 
>> always get the URL, it should work that way for RDB-based contained objects 
>> too.
> 
> I'm not sure it's worthwhile following the "it should work like
> ZODB-backed objects" pattern.

The nice property of ZODB-backed objects is that they're just plain 
Python objects, and it's also familiar to me, so that's why I look for 
special reasons to diverge from it.

Regards,

Martijn