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 particular needs."""
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 problem".

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
>> sense.
> 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 machines,
> 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 particular
> needs.
> As an example, I'm the titular head of the SpamBayes project:
>     http://spambayes.sourceforge.net
> 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 searching
> abilities are a perfect fit to what SB needs.
> Are you quite sure that someone else's idea of a general-purpose searching
> facility is something you'd actually use?  Don't underestimate the
> difficulties in crafting a "one size fits all" approach here that actually
> 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

Reply via email to