On Mar 22, 2008, at 1:34 PM, Roché Compaan wrote:

On Sat, 2008-03-22 at 04:55 -0400, Sean Allen wrote:
On Mar 22, 2008, at 3:50 AM, Roché Compaan wrote:

On Fri, 2008-03-21 at 22:49 -0400, Sean Allen wrote:
And we want to change the the description of Widget B and have that
change appear for everything, how do I do that?
basically, I want all LineItems for Widget A to all refer to a single
instance of Product.

If you simply assign the product to an attribute on the line item, it
will create a reference in the ZODB. And you can use zc.relation to
index and query the relation.

# get the product from your products container:
product = productfolder['ProductXYZ']
# assign it to the line item instance
lineitem.product = product

It's really that simple! If you change the description attribute of
referenced product, all line items referencing it will show the new

Ha! Ok.

Questions then from there.

Why not store each object type,

customer, order etc in their own folders?

You could, and I understand that you want to do so coming from a RDBMS
world, but if you are working with objects then you have the luxury of
organising content in a way that is closer to reality. I think it is
rather convenient to store a customer's orders inside it.

I can see the convenience. Ok, so here is a big question...
Assuming you did store each object in its own folder and you had

    has many orders

At what point do you have to hook into zodb so that if you say did this:

customer = Customer( ... )
customer.addOrder( Order( ... ) )

that the order in question when customer is saved, gets saved to its own folder
and then customer gets a reference to that now saved persistent order
before it itself is saved.

There is another good reason - it makes a lot more sense to distribute
object creation to different containers in the ZODB to avoid write
conflict errors.

I think I understand this but can you elaborate?

By 'distribute object creation to different containers' do you mean store each
object in own folders?

is there a reason to have a folder that contains a more complete graph?
what advantages would that have? speed of access?

What do you mean with "more complete graph"?

storing line items inside  orders inside customers type scenario


the database i am looking at moving over has

1.2 million entries in a transactions table
980,000 orders
775,000 customers
1.5 million order items

I think these numbers are quite manageable. But think carefully what
kind of queries you want to do on the data. You have a very rich query
language in SQL that allows the construction of complex queries and it
will come naturally to you. To do the same in the ZODB will take careful

Are there any mistakes that people usually make when doing this sort
of mental context switch that you can make me aware of now?

Any good reading on the subject?

Either there isnt a ton of information on this on the net or my google skills
are slipping.

and probably another 600,000 other assorted entires that would
be needed in an oo scenario ( tons of join table entries get ditched
tho, nice! )

what type of server setup etc would be needed to handle that load
considering that currently, 40,000 new orders go in a month
along with the corresponding numbers of customers etc.

It depends a lot on the concurrency. It is usually advisable to not
compromise on server architecture, but be sure to get a server with
enough RAM (nothing less than 4GB) and very fast disks.

this will def. be a point when we step up our servers. we have been able to run all this so far with nginx front end that proxies to 20 or so mod_perl processes
and mysql 5 + a 60 meg memcache ( for semi dynamic page storage ) all on
one machine that has a 4 gigs of mem, sata with raid 1 and a quad core 1.6 ghz processor.

somehow i just dont think we are going to be able to get away with that with an oodb.

and again, thanks for help.

-- Sean_______________________________________________
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to