[ZODB-Dev] Re: so your coming from the rdbms world tutorial?

[Sean Allen]

On Feb 27, 2008, at 10:40 AM, Gary Poster wrote:

>> Been over that. Still have serious questions. And yes, we have a  
>> large number of objects, something in the area of 16 million at  
>> present if you were to map each relational table row to an object.
>>
>> The biggest concern I have is how do to the layout/storage so that  
>> this slightly contrived example works:
>>
>> Product has a brand.
>> There are many brands.
>>
>> How do I store so that I can find all products simply and all  
>> brands simply and also so that changes in a brand instance are  
>> reflected when
>> the product instance is deserialized. By 'simply' I mean that it  
>> doesnt really work on our end to have to walk all Products looking
>> for unique brands. Should just be able to go directly in and get  
>> said brands ( using keys() or similar call ).
>>
>> If I create 'brand' and 'product' as btrees, then if i do something  
>> like
>>
>> some_product.brand.name = 'something entirely different'
>>
>> and that brand already exists in 'brand', would it be updated? are  
>> references maintained in that fashion?
>> do we have to handle manually on update and creation?
>>
>> Note that we would just be using ZODB not Zope in this scenario.
>
> Back references are not maintained automatically.
>
> I'd identify two classic solutions to this sort of thing.
>
> One is to make a custom mapping (using a BTree as the inner data  
> structure) that maintains back-references when objects are placed in  
> them or removed.  zope.app(.container? .folder? I'd have to look)  
> has code that does this, along with firing events.  For simple  
> stories like the one you describe here, that's what I'd probably  
> recommend.  It works to the strengths of the ZODB, which  
> particularly shines in terms of readability when you just need to  
> walk a tree of attributes to get what you want.
>
> The other is to keep an external index, a la zc.extrinsicreference  
> or zc.relation.
>
> zc.extrinsicreference does not have too many dependencies beyond  
> ZODB, and as long as zope.app.keyreference doesn't drag much along  
> with it, might be usable as a library.  That said, it's also very  
> simple, and could be used as a model for you, even if you don't use  
> it directly.  It would also be a reasonable choice for a simple  
> situation like the one you describe.  It relies on events to update  
> its data structures.
>
> zc.relation an almost-released-revision of zc.relationship that  
> drastically reduces dependencies--actually, it has no additional  
> dependencies to ZODB, as you can see at http://svn.zope.org/zc.relation/trunk/setup.py?view=markup 
> .  It's also a bit overwhelming and low-level: see the README:http://svn.zope.org/zc.relation/trunk/src/zc/relation/README.txt?view=auto 
>  .  It doesn't hook anything up for you: you set the relationship  
> catalog up and you arrange for it to be updated, via events or  
> direct messages.  That said, if you need its power, it is well- 
> tested and would be a good choice for some jobs from at least some  
> perspectives (caveat read-or: I'm the author).
>
> HTH

I've been playing with this and I'm still having a disconnect 3 week  
later.

1. I love the zc.relation stuff it answers one area of stuff I hadn't  
even gotten to yet.

2. I'm just totally missing something

If I have Customers and Orders and I want to be able update all of  
them independently of their relationships ( so that if an order is  
updated, when i get the customer at some later time, it has the  
updated order amongst that relation ) but I can't figure it out. I  
tried looking at the zope.app.folder stuff but I keep getting lost in  
the zope aspects of it and am having a hard time seeing the forest for  
the trees.

Is there some more general ready on the patterns used that you know  
of? I think if I understood the idea more in an abstract sense, I  
could get a lot more out of the folder implementation.

Thanks for your help,
Sean