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

[Sean Allen]

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
>>> the
>>> referenced product, all line items referencing it will show the new
>>> description.
>>
>>
>> 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

Customer
     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
> planning.

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