lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Flex & Docs/AndPositionsEnum
Date Tue, 09 Feb 2010 13:35:44 GMT

It's great that you're testing the flex APIs... things are still "in
flux" as you've seen.  There's another big patch pending on

Out of curiosity... in what circumstances do you see a Multi*Enum appearing?

Lucene's core always searches "by segment".  Are you doing something
external (directly using the flex APIs against a


On Tue, Feb 9, 2010 at 8:04 AM, Uwe Schindler <> wrote:
> Hi Renaud,
>> On 09/02/10 12:16, Uwe Schindler wrote:
>> > In flex the correct way to add additional posting data to these
>> classes would be the usage of custom attributes, registered in the
>> attributes() AttributeSource.
>> >
>> Ok, I have changed my codes to use the AttributeSource interface.
>> > Due to some limitations, there is currently no working support in
>> MultiReaders to have a "view" on the underlying Enums, but we are
>> working on that.
>> >
>> But, I have still the same problem, it seems that
>> MultiDocsAndPositionsEnum does not have access to the underlying
>> attributes added to my DocsAndPositionsEnum subclass. I got the
>> following exception (IllegalArgumentException):
>> "This AttributeSource does not have the attribute
>> 'org.sindice.siren.analysis.attributes.TupleAttribute'."
>> Is this related to your previous comment, i.e., that MultiReaders do
>> not
>> have a view on the underlying Enums ?
> Exactly, MultiEnums have their own attributes at the moment, there is no "Proxy" view
on it. For this to work, proxy AttributeImpls are needed and there is no support at the moment.
> See
> The problem behind is that when a consumer gets/adds an Attribute, all subreaders  must
use the same attribute or the MultiReader/DirectoryReader must proxy the attributes. For this
to work we need dynamic proxies or you also have to implement ProxyImpls: Attribute, AttributeImpl,
> We have no progress for that at the moment, so I am sorry, we have no working support
for attributes in MultiReaders (which all DirectoryReaders are, because a index could consist
of more than one segment).
>> > In general what you do (if it works in future):
>> > Define an interface for your extensions based on the Attribute
>> interface and also provide the implementation class. Then call
>> YourEnums.attributes().addAttribute(YourInterface.class) in the ctor of
>> your enum, store a local reference to the attribute and fill this on
>> iteration. Any consumer of this Enum can check using
>> TermPositions.attributes().hasAttribute/getAttribute/addAttribute for
>> the existence of the the same and then read the attributes during
>> iteration. There is no need to change the Enum class API at all.
>> >
>> Ok, it works like a charm except the problem related to MultiReaders.
> See above.
> But attributes are the way to go for this extended posting/prox lists.
> Uwe
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message