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

Hi there,

On Tue, Jun 3, 2008 at 3:28 PM, Sean Allen <[EMAIL PROTECTED] > wrote:
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

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

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.

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to