Please do not forget that I am not a real programmer but a consumer:
0. I accept if the policy is making ZODB just for Zope. Then OK.
But if there is bigger potential inside it... (By the way: I think it is
great and big, and I would like to use it.)
To formulate this on a more realistic way: it seems for me that there is
no potential to take care about this extra project outside of Zope
AND/OR it would not be good for Zope developers to have it as an
easy-to-use stand alone module (maybe some business policy?).
1. """That's usually viewed as an application-level problem, and
it's up to applications to solve it in ways best suited for their
If I translate this for myself, if I understand well:
I am very happy that RDBMSs does not say this, and I can search them not
only by primary keys; I am happy that I do not have to implement
something similar to SQL as it is not considered as "application level
2. BTrees: I could not find any 'built-in' possibility in the docs, just
the 'primary keys'. If I check the OOBTree, etc, it just give
'difference', 'intersection', 'union'.
I do not see to do full text search or field search on BTrees.
Do I miss something??? (I do not think as if I would than you would not
call the problem "application" level problem).
3. I can not build up another database from the ZODB as I am not a
developer. But I think you formulated this not the best way: I think you
do not build the SB database OUT of ZODB's BTrees, I think you just
build up indexes from the BTrees and you implement searches on your
indexes that points back to the BTrees.
=> If you build up a new database why do you use ZODB?
=> If you just build indexes from the BTrees, the following protocol
works for me and you can suggest?
1. walk trough on your BTree taking each object
2. with an external indexing application build the index (on one or more
fields, or full text)
3. search in your index that returns with the 'primary key' of objects
in the ZODB
4. get the objects from the ZODB via the 'primary keys' from the prev step.
Thanks for your comments and suggestion in advance,
Tim Peters wrote:
> [Tamas Hegedus]
>> You have released the ZODB/ZEO as a stand alone package. But there is no
>> stand alone searching possibility. Why? This just does not make any
> It makes sense if you know why ZODB is released this way ;-) Primarily,
> it's so that people running Zope can install ZEO servers on other
> without needing to install Zope there too. If others can make use of
> standalone ZODB too, that's great, but it's not the primary intent.
> There are no current plans to add index/catalog/search code to the ZODB
> distribution. That's usually viewed as an application-level problem, and
> it's up to applications to solve it in ways best suited for their
> As an example, I'm the titular head of the SpamBayes project:
> and we're in the process there of adopting ZODB as the default backend
> database. While SpamBayes needs to search its database frequently and
> heavily, there's nothing ZODB could add that we would use! Instead we'll
> build the SB database directly out of ZODB's BTrees, whose builtin
> abilities are a perfect fit to what SB needs.
> Are you quite sure that someone else's idea of a general-purpose
> facility is something you'd actually use? Don't underestimate the
> difficulties in crafting a "one size fits all" approach here that
> fits anyone ;-)
Tamas Hegedus, PhD | phone: (1) 919-966 0329
UNC - Biochem & Biophys | fax: (1) 919-966 5178
5007A Thurston-Bowles Bldg | mailto:[EMAIL PROTECTED]
Chapel Hill, NC, 27599-7248 | http://biohegedus.org
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org