[Seaside] Re: GOODS

[Sebastian Sastre]

> I don't want to interrupt Sebastian as I'm sure he has some 
> very good reasons for not liking GOODS. But I do want to add 
> that there are several of us using it in production and it is 
> a great persistence solution in Squeak. The only problem I 
> really have with it (which is not a GOODS problem but a 
> Squeak problem) is that commits can be very slow if you have 
> loaded a lot of objects in a transaction. That is, when you 
> commit the Squeak client needs to check all of the objects 
> loaded in your transaction from the database to see if any of 
> them are "dirty" 
> (have been changed since they were loaded). This process 
> involves a linear search which can be very slow when you have 
> a lot of objects loaded. I added the method #cacheSize to 
> KKDatabase in order for me to be able to monitor this. This 
> problem might be solved by WriteBarrier but I've never been 
> able to get that to work efficiently. In the mean time I have 
> several Squeak/Seaside production applications using GOODS 
> and, with some small tuning here and there, they all chug 
> along nicely.
> 
> David
> 
Oh Davis please be my guest to add whatever you experienced in this
discussion. I recognise I've tried GOODS (I even made a port of the squeak
client to dolphin smalltalk some time ago) and failed to use it reasonably
for a system of about 40k objects. Even with Btrees and such I was unable to
achieve a half of what I got with any other persistance mechanism. I didn't
work for me.
I see GOODS as a layer of ACID writting of scrutcures in disk not as a more
complete persistence solutions. That gap it's covered by the Avi's Squeak
client of course but with write barrier and all it is still a no go for me.
On the other hand I'm having a good experience with Magma. I moved from
ImageSegments to a magma repository in one day.

Cheers,

Sebastian