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
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
