I think you can still achieve your desired outcome, but I'm not sure I fully
understand the use case. Can you describe more clearly a specific example
of what you need to achieve?
You are correct that "joins" in lucene aren't really a strong point, but
this is often a by-product of thinking abou
thanks Jason and Steve;
maybe i didn't understand your solution well, but in this system a document is
refered many times (we have a refer description wich we should index it also)
and each time a document is refered i should update it in the lucene index and
so i should delete it and then index
As Jason says, you can structure each Lucene document with one Field per
content type, and index all data that way. The database is not required.
To address your search complexity concern, you can create queries that
search only those Field(s) the user wants -- there is no need to have a
Field fo
Maybe I'm not understanding your requirement, but this should be fairly
simple in Lucene.
Each document in your document management system would be represented by a
single Lucene document in the index. Each lucene document will then have
several fields, each field representing the values of the
Hi all;
We have got a Document management system and we want to build a search on it.
We have tree kind of content in our system: Refers, Documents and Attachments.
A document can have multiple attachments and can be Refered to many users.
Our users want to be able to search on documents attachme
