Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
so if zodb has no index or search, how run fast query?
14 views
Skip to first unread message
vispha...@gmail.com
May 16, 2013, 2:14:44 PM5/16/13
to
how?
and what package provides such?
and what package provides such?
alex23
May 16, 2013, 8:08:49 PM5/16/13
to
https://pypi.python.org/pypi/zope.index
https://pypi.python.org/pypi/zope.app.catalog
I can see how those would be pretty difficult to find...
https://pypi.python.org/pypi/zope.app.catalog
I can see how those would be pretty difficult to find...
dieter
May 17, 2013, 2:47:46 AM5/17/13
to pytho...@python.org
vispha...@gmail.com writes:
> ...
The only service of the ZODB is storing (persistent) objects
persistently and providing (almost) transparent acces to them.
Persistent objects have a (usually) implicitely
managed attribute which contains the object's "object id"
and the ZODB can (quite) efficiently access the objects based
on its "object id" (it is using caches and indexes for this).
The objects managed by the ZODB form a (directed) graph with
a distinguished root node - where all nodes are (persistent)
Python objects. You essentially work with those persistent objects
as with normal Python objects: the ZODB transparently accesses
the persistent storage, when necessary, to give you
the feeling as if those objects were normal Python objects.
There are a few caveats with respect to modifications -
but most modifications work as you would expect for
"normal" Python objects (however, you must call "transaction.commit()",
in order to persist the modifications).
That is essentially all, the ZODB does for you.
When you need searches, you must use appropriate datatypes --
in the same way, you would need to do this in a "normal" Python program.
The ZODB comes with a collection of datatypes (so called "BTrees")
which may form the base for searches.
"BTrees" are essentially persistent dicts - however, they
are not build from a fixed number of persistent subobjects but
the persistent substructure is changed automatically to accommodate
efficiently for various tree sizes.
Someone else has already mentioned some higher level packages which
can provide search capabilities.
> ...
The only service of the ZODB is storing (persistent) objects
persistently and providing (almost) transparent acces to them.
Persistent objects have a (usually) implicitely
managed attribute which contains the object's "object id"
and the ZODB can (quite) efficiently access the objects based
on its "object id" (it is using caches and indexes for this).
The objects managed by the ZODB form a (directed) graph with
a distinguished root node - where all nodes are (persistent)
Python objects. You essentially work with those persistent objects
as with normal Python objects: the ZODB transparently accesses
the persistent storage, when necessary, to give you
the feeling as if those objects were normal Python objects.
There are a few caveats with respect to modifications -
but most modifications work as you would expect for
"normal" Python objects (however, you must call "transaction.commit()",
in order to persist the modifications).
That is essentially all, the ZODB does for you.
When you need searches, you must use appropriate datatypes --
in the same way, you would need to do this in a "normal" Python program.
The ZODB comes with a collection of datatypes (so called "BTrees")
which may form the base for searches.
"BTrees" are essentially persistent dicts - however, they
are not build from a fixed number of persistent subobjects but
the persistent substructure is changed automatically to accommodate
efficiently for various tree sizes.
Someone else has already mentioned some higher level packages which
can provide search capabilities.
0 new messages