[Zope3-dev] zwiki: performance of findChildren()

[Jeffrey P Shell]

Well, then we get into the design issue of 
Bob.receipts.receipt1.purchaser pointing back to Bob.  Actually, I just 
don't know how to design for this scenario in the ZODB/Zope.  I've 
heard that (at least, up until recently) maintaining hard persistent 
links to objects elsewhere in the tree was a bad thing to do.  Even now 
- for some reason, I'm scared of doing it (maybe it's just the lack of 
an event framework to catch deletes, etc).

I'm used to the relative ease of joins in SQL, yet in ZODB I often feel 
rather constrained by the containment-only relationships (or have to go 
out of my way to build catalog indexes, or do BTrees, path lookups, 
etc).  I'm curious about moving out of this sphere, yet having the same 
relative ease I get out of an RDBMS/SQL to be able to relate one thing 
to another almost arbitrarily.

Weak references are not a particular design decision.  I was just 
thinking of a way of spelling "I'm interested in this object that I 
don't contain".  Most likely, I want to have some sort of extra data 
about that relationship/reference on the reference, and weakref just 
came to mind as the shortest way of (apparently) incorrectly stating 
that ;).

On Tuesday, April 22, 2003, at 02:31  PM, Jeremy Hylton wrote:

>> Doing weak references between business objects in the system is my
>> el-numero-uno wanted feature.
>
> Why do you want weak references in particular?  I don't understand what
> purpose weak references serve in ZODB.  In regular Python, a weak
> reference allows the memory for an object to be freed while someone is
> holding weak references to it.  In ZODB, the process memory is managed
> by the object cache, which some limit or possibly eliminate the need 
> for
> a weak reference.  The storage space isn't going to get freed by a weak
> reference anyway, because pack doesn't work that way.
>
>> What I'd ultimately like is something
>> like the following::
>>
>>    People
>>     |
>>     +--Bob
>>
>>    Receipts
>>     |
>>     +--Receipt1
>>     |
>>     +--Receipt2
>>
>>
>>   in: Receipt1.purchaser = People.Bob
>>       # maybe some sort of weakref(People.Bob)?
>>   in: Receipt2.purchaser = People.Bob
>>   in: Receipt2.purchaser.name
>>   out:  'Bob'
>>   in: Reciept2.purchaser.name = "Robert"
>>   in: Receipt1.purchaser.name
>>   out:  'Robert'
>>
>> IE - How can we do one-to-many, many-to-one, many-to-many, and
>> one-to-one (non-containment) relationships in the ZODB that is
>> relatively natural?  Why wouldn't an ObjectHub fill these scenarios?
>>
>> I want to wean myself off of SQL as soon as possible, but optimized
>> Querying and Relationships are still a tough point in Zope/ZODB.
>
> Why don't collections -- persistent dict and lists and BTrees -- 
> fulfill
> this need?

Because there's no mention about the impact of one to many references 
to another persistent object in another object tree.  Sometimes I think 
about making a reference and changing the acquisition, and then I get 
yelled at about potential security risks.  I always hear why I 
shouldn't, or why I should be careful when doing it, or how some 
upcoming version of the software may address the issue (but no mention 
of it ever shows up).  And it's one of the reasons we keep ending up 
putting up with relational databases to store business objects in.

And also, because there has been no event tool up until now, so just 
storing a path and building a connection to an object from that path 
often feels like an exercise in hope - hope that the path will stay 
faithful to the object one wants at all times.  We try to program 
around this by making our applications that need to keep track of such 
inter-object links as solid as possible, but something always leaks 
through now and again.

I hope I'm explaining this well.  I'm just realizing that I really 
don't know how to try to integrate an existing relational model and 
application into Zope via Ape, and this is the main sticking point.  
And that's not even ZODB related - it's just the Zope development 
paradigm I've found myself in over the years, which stems from the 
"yeah, you don't really want to make links like that" statement that's 
come up time and again.

It's been almost a year and a half since I first posted a question 
about how this will work in Zope 3.  I think that the ObjectHub quickly 
stemmed out of that, but what I'm hearing is that there's still no way 
for me to write the business applications that I would really like to 
write, now that Gary's said that the ObjectHub is the basis to build 
what I want, but it's not what I want.  And I wish I had the skills and 
time to put in here, but these other apps that are barely paying the 
bills sadly come first. :\

http://mail.zope.org/pipermail/zope3-dev/2002-January/000407.html

Note: in that message, I mentioned a Zope/CMF app that needed 
relations.  I don't think mxmRelations existed at the time, so I ended 
up writing my own relationship manager and event framework.  This ended 
up putting me so far behind schedule (fortunately it was just an 
internal-use system) that it was the nail in the coffin for this whole 
project, which is still a bitter taste in my mouth.  So, I apologize if 
I come off a bit offensive about this issue.  It's the one wall I crash 
against more often than any other.