On Saturday, November 29, 2003, at 07:00 AM, Stefano Mazzocchi wrote:
I think you'll find that Lucene will serve Slide's needs nicely - you'll just have to be a little creative in how you build Lucene Document objects and break things into fields. Lucene is a "flat" structure - so implying hierarchy requires some thought - perhaps just the URI will work to give you the hierarchy you need. But if properties are also hierarchical (can't non-live, "dead"?, properties contain an entire DOM tree?) then things will get more interesting and tricky.
Hmmm, seems to me like trying to fit a square into a rounded hole.
Perhaps. But, folks are doing object-relational mapping with databases. A database could be viewed as simply a flat structure of bytes on a disk. So, mapping Lucene's flat structure into something more structured and hierarchical is do-able. ZOE (the e-mail client-server-indexer) does a lot of this type of stuff using Lucene, in fact.
But, certainly it is just one possible solution and may not be the most pragmatic one. If a database is being used for property storage already, then Lucene might be overkill for a query like you provided.
It would be nice if it was possible to abstract from the RDBMS as the property storage for two reasons:
1. Slide was designed to map multiple stores to different URI paths. This means having a global index would allow to search all stores with a single request
2. The default download and go version of Slide uses the file system only. To have a reasonable performance here would not be crucial, but at least nice
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
