[ZODB-Dev] Re: Ruby/Smalltalk OODB

[Martijn Faassen]

On Tue, Jun 3, 2008 at 5:28 PM, Sean Allen <sean at monkeysnatchbanana.com> wrote:
[snip]
> What is different is that persistence is built into their vm.
> You just put anything into any global and its persisted.

Okay, that's like the PyPy approach and cannot be done really without
doing it on the interpreter level.

>> How does Gemstone implement efficient querying or indexing?
[snip]

Okay, this sounds like an indexing framework built into the database
layer, something the ZODB doesn't have, but of course has been built
on top with the catalog.

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

Fullstack has its advantages, though also disadvantages. It means they
need to reimplement compliant interpreters for any language they want
to support, and that's going to hurt their library support. (as I
doubt arbitrary CPython extensions would work with a hypothetical
Python version of this)

[snip]
> 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.

This is something ZEO also provides, as far as I can grasp from your
description.

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

I'd say that the ZODB by itself also doesn't put heavy requirements on
your code. The main thing is the subclassing from Persistent, and
_p_changed flags if you use non-persistent subobjects you still want
to persist.

For indexing, a framework like Zope 3 requires zero changes to the
classes themselves.

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

ZEO should do just that. I understand you have an object A which has a
reference to B. You also have a dictionary that has a reference to A,
and a dictionary that has a reference to B. Both A and the dictionary
will be pointing to the same instance of B. (if A and B are both
subclasses of Persistent. If not, it might be both serialize
separately, I'm not sure).

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

I'm confused. This has been the way the ZODB worked for a long time,
unless I'm really missing something in your description.

Regards,

Martijn