[Grok-dev] Re: STORM howto

[Sebastian Ware]

** On preformance **

I uncommented the offending ;) line and the performance went from a  
useless...

   Performed 100 transactions; Buy = 24; Sell = 76
   start: 2008-03-13 23:13:19.572152
   end: 2008-03-13 23:13:26.543223
   diff: 0:00:06.971071 <<<<<<<<<<<<<<<<<<<<<< 7.0 seconds (commit on  
each insert)

to an excellent... (yes, I double checked that the data was written to  
the db :))

   Performed 100 transactions; Buy = 24; Sell = 76
   start: 2008-03-14 11:28:13.045482
   end: 2008-03-14 11:28:13.372686
   diff: 0:00:00.327204 <<<<<<<<<<<<<<<<<<<<<< 0.3 seconds (singel  
commit)

persisting to Zodb gave me the following result... (there is no  
practical difference between buy and sell)

   Performed 100 transactions; Buy = 16; Sell = 84
   start: 2008-03-13 23:21:55.655146
   end: 2008-03-13 23:21:56.645960
   diff: 0:00:00.990814 <<<<<<<<<<<<<<<<<<<<<< 1.0 seconds (singel  
commit)

** On order of persistence **

Something that was interesting however is that the lines were written  
in a different (random) order than the objects were assigned to the  
container. Is this the intended behaviour?

I think this is a bad idea, because it come as a surprise (at least to  
those who have been used to working with databases).

Mvh Sebastian

14 mar 2008 kl. 10.29 skrev Christian Klinger:

> Wichert Akkerman schrieb:
>> Previously Christian Klinger wrote:
>>> Sebastian Ware schrieb:
>>>> Do I add nva.stormcontainer in setup.py in order to fetch this  
>>>> egg? I would like to try it.
>>>>
>>> Yes this should do it. Hopefully...
>>>
>>>> Also, is there any way I can control the commits? I am basically  
>>>> doing:
>>>>
>>>> for obj in objlist:
>>>>   ormContainer['id'] = obj
>>> In the stormcontainer there is a __setitem__ which is responsible  
>>> for the insert.
>>>
>>>    def __setitem__(self, name, item):
>>>        store = getUtility(IZStorm).get(self.getStoreUtilityName())
>>>        store.add(item)
>>>        transaction.commit()
>>>
>>> The transaction.commit() fires also an rdb.commit. This means on  
>>> every insert there is a commit.
>>>
>>> But maybe it is possible to delete the transaction.commit() in  
>>> __setitem__, and rely on zopes transaction.commit.?
>> I do not think any library or framework should ever do a commit  
>> itself.
>> You should hook properly into the zope transaction manager. Any
>> premature commit can result in inconsistent or erroneous data in your
>> database. And reducing the number of commits will have a huge  
>> impact on
>> performance.
>
> Hi Wichert,
>
> thx for this info. I will delete the transaction.commit() run the  
> tests. and see if it works again... :-))
>
> Christian
>
>> Wichert.
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev