Renaud, 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 LUCENE-2111...
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 Multi/DirectoryReader)? Mike On Tue, Feb 9, 2010 at 8:04 AM, Uwe Schindler <u...@thetaphi.de> 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 https://issues.apache.org/jira/browse/LUCENE-2154 > > 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, > AttributeProxyImpl. > > 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: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
