[ZODB-Dev] Re: Ruby/Smalltalk OODB

[Sean Allen]

On Jun 3, 2008, at 10:52 AM, Martijn Faassen wrote:

> Hi there,
>
> On Tue, Jun 3, 2008 at 3:28 PM, Sean Allen <sean at monkeysnatchbanana.com 
> > wrote:
> [snip]
>> i dont think you can compare ZODB to gemstone's products. i've  
>> looked at
>> both over the last few months with a decent level of depth and the  
>> gemstone
>> from a programmer's standpoint is infintately easier to use. no  
>> special
>> classes, no nothing really. just put anything persistent in a global
>> dictionary and blam its done.
>
> The ZODB can be used that way; the root object *is* a global
> dictionary. Admittedly Persistent is necessary to make sure that
> attributes changes are persisted; this may be nicer in Gemstone. Or do
> you mean any global dictionaries are persisted?

That part is the same.

What is different is that persistence is built into their vm.
You just put anything into any global and its persisted.

>
> How does Gemstone implement efficient querying or indexing?
>

under the hood or application level?

there are two on the application level. you can use standard  
collection methods
on the persistent instances, this isnt indexed OR you can use their  
custom
block statement syntax ( i'm talking just the smalltalk now ) to work  
specifically
on indexes.

indexes are established by sending a message to the class of whatever  
you
want to index.

under the hood?

i haven't looked into the specific details of how they wire it  
altogether but it comes down
to, gemstone is a fullstack. whether you are using the smalltalk, java  
or eventual ruby...
they write the vm which has primitives to make their ops fast, has  
built in persistence
so you just dont think about it at all. in fact, you have to ask for a  
class to not be
persistent.

> I know the PyPy people have a demo where multiple interpreters share
> objects transparently, so perhaps this is closer to what Gemstone
> does.
>

that would be closer yeah on some level.
it goes back to that full stack thing. gemstone isnt just an oodb.
its an oodb, its a scaling solution, its a vm.

theres an object store shared by all. there are multiple vms instances  
running whatever code and the
entire thing can run across multiple machines... need to scale, add  
more machines in.

i'm still digging into it all, its only been 3 weeks so i still have a  
lot of the terminology wrong etc,
but it really is a very cool product. not having to think about the  
data store is just real nice.
its all just objects and you dont have to change anything about how  
you code for them unless
you want to use indexes and then the changes are very minor.

>> pull it back out and there it is again, object pointers fully  
>> intact. store
>> in 2 different directories, modify in one, blam! modified in the  
>> other.
>
> I'm not sure how this is different than using the root object to store
> objects and ZEO?
>

if i have customer A who has order B

and i store customer A to customer dictionary
and order B to order dictionary

then later  access order B from order dictionary, modify and update it

does ZEO update the instance of order pointed to by customer A?
I cant get it to do it. My understanding is it cant. Well, it could
but it isnt 'right out of the box' seamless.

If you do that in gemstone, there is only one copy of Order B, no matter
what variable in what dictionary you come at it from. And its drop  
dead simple.

I looked at implementing that with zodb and moved along.