I think this could be done more general, such that every time a document
is changing is being indexed, e.g. also after editing, whereas there
could
be one index for the authoring and one index for the live area.
If the document changes, it will be reindexed. I don't really see the
need of a seperate index for every area.
within the authoring area the content can be quite different. Also there
can be
documents which don't exist within the live area. I think it definitely
makes
sense to have different indices or rather being able to search on
"different versions"
re workflow status.
I don't think it will be much more work to implement, but rather keep
the interface
general enough and maybe just implement the live area if time it too
limited for you.
But I'd suggest that you rather drop some othe features and focuse on this.
I don't think i have the time to change the proposal. The deadline is
tomorrow. I don't think this is difficult to implement: add a field to
Lucene with the area and add a hidden field to the search form. It would
also need the indexing of the document in the submit step. This should
be fairly easy to add when i am working on it.
Changing the fields would require a change of the 'obsolete' xml
documents, but i think this is a rare case that should actually be
avoided. Fields can be added or fields can become obsolete without a
problem, but changing a field is something that is done rarely, if
ever. Could you give me a scenario where this would be an urgent problem?
let's say you have one title field, and then one adopts the schema that one
has a maintitle and a subtitle and title will be gone, whereas the title
is becoming
the maintitle
I would say: keep the title and add a field subtitle:)
I think changing a field is not something one should do often, also
because of the iterative nature of the index building: the index isn't
rebuilt but changed when a document changes. Making a complete change of
the field in the index just does not fit into this idea.
One could, of course, change all documents. This would also cause the
document to be reindexed. For this obscure occasion, one could write a
simple script to run trough the documents that have to be changed.
I am not sure if i should add it to my proposal, due to time
constraints. Do you think this is a major issue?
<pr>
<title>
<lenya:index>title</lenya:index>
Lenya 14 release preponed
</title>
<content>
<lenya:index>contents</lenya:index>
The release of Lenya 1.4, the Apache Content Management System, ladila
</content>
</pr>
how do you want to mark attributes?
Hmm. Good question. I don't see the need for this in my current
documents, but it should be possible, of course.
The lenya:index element could have an attribute to select the indexable
attribute.
Besides this: the lenya:index element should have an attribute to define
the selection of the child elements. One could ony index the content of
the current element or also include the child nodes. This would be the
case with the <body> element of an XHTML page.
<lenya:index fieldname="title" includechilds="false" indexattr="test">
When one wants to add some element to multiple Lucene fields, the
lenya:index element should be added a number of times.
Any other remarks?
how do you want to treat these external links?
I was actually rather thinking about how to do you want to handle them
within the index, because they won't have the same fields as the ones
within Lenya. Do you want
to create a separate index?
Ah, ok! I want to add them to the same index. Having some field unfilled
is no problem in Lucene. I could consider using the keywords of the
document that contains the links, but this seems very nasty to me...
As far as i can see, it contains all the output one can ask for from a
Lucene query.
also pagening?
Yep. Pretty nice implemented!
no problem, thanks very much for working on it. Please don't be afraid
of my comments (in case you are), but I just want to make sure that
various things are being
considered.
Quite the contrary! It is a delight to know that people are actually
reading it thoroughly. Thanks!
I would like to send the proposal at the end of this afternoon. Are
there some major issues that should be changed or added?
Regards, Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
