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:
[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.
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
