Re: 9.0 release
+1 On Tue, Dec 29, 2020 at 8:43 AM Erick Erickson wrote: > > It’ll really be nice to not have to switch between gradle and ant when > verifying changes ;). > > Not to mention that we’ll be able to stop having to deal with Java 8 > .vs. Java 11. > > I don’t expect this to be a short release, so yeah, I think it’s time to > start the process. > > Erick > > > On Dec 28, 2020, at 2:36 PM, Atri Sharma wrote: > > > > +1 > > > > I think the division steps are pretty clearly documented-- a matter of > > executing them now. > > > > On Tue, 29 Dec 2020, 01:03 Dawid Weiss, wrote: > > It would be great indeed if we could push to finalize dividing the > > codebases (some things have been proven to be doable - snapshot > > builds, splitting the code, > > build, etc.) and then follow up with proper releases of both Lucene > > and Solr (on their independent TLP). > > > > > > Dawid > > > > On Mon, Dec 28, 2020 at 7:17 PM Michael Sokolov wrote: > > > > > > Hi everyone, as we head into a new year full of optimism, is it time > > > to start discussing the next major release? We released 8.0 on Jun 18, > > > 2019, over 18 months ago. Since then we've switched to a gradle-based > > > build. We have added vector-valued fields and an HNSW neighbor search > > > algorithm for them. At the same time Solr has been getting a major > > > overhaul which should justify a release, I think? IIRC there was talk > > > of making 9.0 be the first release of Solr as its own TLP. Is it time > > > to start planning for that now? > > > > > > -Mike > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Lucene] Add javadoc for Lucene86PointsFormat class
Thanks David 发自我的iPhone > 在 2020年12月28日，21:43，David Smiley 写道： > > > You now have access. Sorry for the delay! > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > >> On Wed, Dec 23, 2020 at 8:44 PM LuXugang wrote: >> Thanks David >> >> My userId is luxugang >> >> <1.png> >> >> >>> On Dec 23, 2020, at 21:31, David Smiley wrote: >>> >>> Please register at the ASF's Confluence / wiki space. Then tell me your >>> userId, and I will then grant you permissions to edit our wiki. >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> On Wed, Dec 23, 2020 at 2:50 AM LuXugang wrote: Hi, David Here the link on my personal website to introduce index file .kdd&.kdi：https://www.amazingkoala.com.cn/Lucene_Document/IndexFile/2020/1104/175.html If it’s ok, I would like to rewrite it on https://cwiki.apache.org/confluence/display/LUCENE/Home, but I have no permission to edit. Jira link: https://issues.apache.org/jira/browse/LUCENE-9590?filter=-2 Actually, I have wrote some other articles to introduce Lucene but with Chinese, so if it is needed, I would like to write more in English. > 2020年10月30日 16:57，LuXugang 写道： > > Thanks David, add link in javadocs is great, got it ~ > >> On Oct 30, 2020, at 12:45 PM, David Smiley wrote: >> >> Fantastic contribution! >> >> I don't think we have images in our javadocs, but if you can prove me >> wrong then great! We could link to it from javadocs and host it at the >> Confluence based wiki here: >> https://cwiki.apache.org/confluence/display/LUCENE/Home >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >>> On Wed, Oct 28, 2020 at 11:39 AM LuXugang >>> wrote: >>> Hi, >>> >>> I would like to add javadoc for Lucene86PointsFormat class, it is >>> really helpful for source reader to understand the data structure with >>> point value >>> >>> The attachment list part of the data structure （filled with color means >>> it has sub data structure）<1.png> >>> >>> > >>
Re: 9.0 release
It’ll really be nice to not have to switch between gradle and ant when verifying changes ;). Not to mention that we’ll be able to stop having to deal with Java 8 .vs. Java 11. I don’t expect this to be a short release, so yeah, I think it’s time to start the process. Erick > On Dec 28, 2020, at 2:36 PM, Atri Sharma wrote: > > +1 > > I think the division steps are pretty clearly documented-- a matter of > executing them now. > > On Tue, 29 Dec 2020, 01:03 Dawid Weiss, wrote: > It would be great indeed if we could push to finalize dividing the > codebases (some things have been proven to be doable - snapshot > builds, splitting the code, > build, etc.) and then follow up with proper releases of both Lucene > and Solr (on their independent TLP). > > > Dawid > > On Mon, Dec 28, 2020 at 7:17 PM Michael Sokolov wrote: > > > > Hi everyone, as we head into a new year full of optimism, is it time > > to start discussing the next major release? We released 8.0 on Jun 18, > > 2019, over 18 months ago. Since then we've switched to a gradle-based > > build. We have added vector-valued fields and an HNSW neighbor search > > algorithm for them. At the same time Solr has been getting a major > > overhaul which should justify a release, I think? IIRC there was talk > > of making 9.0 be the first release of Solr as its own TLP. Is it time > > to start planning for that now? > > > > -Mike > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 9.0 release
+1 I think the division steps are pretty clearly documented-- a matter of executing them now. On Tue, 29 Dec 2020, 01:03 Dawid Weiss, wrote: > It would be great indeed if we could push to finalize dividing the > codebases (some things have been proven to be doable - snapshot > builds, splitting the code, > build, etc.) and then follow up with proper releases of both Lucene > and Solr (on their independent TLP). > > > Dawid > > On Mon, Dec 28, 2020 at 7:17 PM Michael Sokolov > wrote: > > > > Hi everyone, as we head into a new year full of optimism, is it time > > to start discussing the next major release? We released 8.0 on Jun 18, > > 2019, over 18 months ago. Since then we've switched to a gradle-based > > build. We have added vector-valued fields and an HNSW neighbor search > > algorithm for them. At the same time Solr has been getting a major > > overhaul which should justify a release, I think? IIRC there was talk > > of making 9.0 be the first release of Solr as its own TLP. Is it time > > to start planning for that now? > > > > -Mike > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: 9.0 release
It would be great indeed if we could push to finalize dividing the codebases (some things have been proven to be doable - snapshot builds, splitting the code, build, etc.) and then follow up with proper releases of both Lucene and Solr (on their independent TLP). Dawid On Mon, Dec 28, 2020 at 7:17 PM Michael Sokolov wrote: > > Hi everyone, as we head into a new year full of optimism, is it time > to start discussing the next major release? We released 8.0 on Jun 18, > 2019, over 18 months ago. Since then we've switched to a gradle-based > build. We have added vector-valued fields and an HNSW neighbor search > algorithm for them. At the same time Solr has been getting a major > overhaul which should justify a release, I think? IIRC there was talk > of making 9.0 be the first release of Solr as its own TLP. Is it time > to start planning for that now? > > -Mike > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: LeafReaderContext ord is unexpectedly 0
That's exactly how this problem occurred. I'll make sure this is fixed before merging into the codebase. Joel Bernstein http://joelsolr.blogspot.com/ On Sun, Dec 27, 2020 at 6:12 PM Uwe Schindler wrote: > Hi, > > > > just to add: Any public query API (weight, query, DocIdSetIterators,…) > should always take LeafReaderContext as parameter. If you have some solr > plugin that maybe implements some method only taking LeafReader, this one > lost context and it’s impossible to restore from that. So if sending > IndexReader instances around (no matter what type), always use > ReaderContexts, especially in public APIs. > > > > Uwe > > > > - > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > *From:* Joel Bernstein > *Sent:* Sunday, December 27, 2020 7:36 PM > *To:* lucene dev > *Subject:* Re: LeafReaderContext ord is unexpectedly 0 > > > > Ok this makes sense. I suspect I never ran across this before because I > always accessed the ord through the context before getting the reader. > > > > > > Joel Bernstein > > http://joelsolr.blogspot.com/ > > > > > > On Sun, Dec 27, 2020 at 1:10 PM Uwe Schindler wrote: > > Hi, > > > > that behaviour is fully correct and was always like that. Just for info (I > had some slides on berlinbuzzwords like 8.5 years ago): > > https://youtu.be/iZZ1AbJ6dik?t=1975 > > > > The problem is a classical “wrong point of view” problem! > > > > IndexReaders and their subclasses have no idea about their neighbours or > parents, they can always be used on their own. They can also be in multiple > contexts (), like a LeafReader (in that talk we used AtomicReader) is > part of a DirectoryReader but at same time somebody else has constructed > another composite reader with LeafReaders from totally different > directories (e.g., when merging different indexes together). So in short: A > reader does not know anything about its own “where I am”. > > > > The method getContext() is only there as a helper method (it’s a bit > misnomed), to create a **new** context that describes this reader as the > only one in it, so inside this new context it has an ord of 0. > > > > The problem in your code is: you dive down through the correct context > from top-level (the top context is from the point of view of the > SolrSearcher), but then you leave this hierarchy by calling reader(). At > that point you lost context information. After that you get a new context > and this one returns 0, because its no longer form SolrIndexSearcher’s > point of view, but its own PoV. > > > > Replace: leaves.get(5).reader().getContext().ord > > By: leaves.get(5).ord > > > > And you’re fine. The red part leaves the top level context and then > creates a new one – an then you’re lost! > > > > Uwe > > > > - > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > *From:* Joel Bernstein > *Sent:* Sunday, December 27, 2020 5:59 PM > *To:* lucene dev > *Subject:* LeafReaderContext ord is unexpectedly 0 > > > > I ran into this while writing some Solr code today. > > > > List leaves = > req.getSearcher().getTopReaderContext().leaves(); > > > > The req is a SolrQueryRequest object. > > > > Now if I do this: > > > > leaves.get(5).reader().getContext().ord > > > > I would expect *ord* in this scenario to be *5*. > > > > But in my testing in master it's returning 0. > > > > It seems like this is a bug. Not sure yet if this is a bug in Sor or > Lucene. Am I missing anything here that anyone can see? > > > > > Joel Bernstein > > http://joelsolr.blogspot.com/ > >
Re: 9.0 release
+1 on starting 9.0 release planning. Nicholas Knize, Ph.D., GISP Principal Engineer - Search | Amazon Apache Lucene PMC Member and Committer nkn...@apache.org On Mon, Dec 28, 2020 at 12:34 PM Timothy Potter wrote: > Hear! Hear! Definitely agree it's time to start planning around 9. Thanks > for initiating the discussion Mike. Will follow-up after the new year with > some specific thoughts around planning. > > Cheers, > Tim > > On Mon, Dec 28, 2020 at 11:17 AM Michael Sokolov > wrote: > >> Hi everyone, as we head into a new year full of optimism, is it time >> to start discussing the next major release? We released 8.0 on Jun 18, >> 2019, over 18 months ago. Since then we've switched to a gradle-based >> build. We have added vector-valued fields and an HNSW neighbor search >> algorithm for them. At the same time Solr has been getting a major >> overhaul which should justify a release, I think? IIRC there was talk >> of making 9.0 be the first release of Solr as its own TLP. Is it time >> to start planning for that now? >> >> -Mike >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: 9.0 release
Hear! Hear! Definitely agree it's time to start planning around 9. Thanks for initiating the discussion Mike. Will follow-up after the new year with some specific thoughts around planning. Cheers, Tim On Mon, Dec 28, 2020 at 11:17 AM Michael Sokolov wrote: > Hi everyone, as we head into a new year full of optimism, is it time > to start discussing the next major release? We released 8.0 on Jun 18, > 2019, over 18 months ago. Since then we've switched to a gradle-based > build. We have added vector-valued fields and an HNSW neighbor search > algorithm for them. At the same time Solr has been getting a major > overhaul which should justify a release, I think? IIRC there was talk > of making 9.0 be the first release of Solr as its own TLP. Is it time > to start planning for that now? > > -Mike > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
9.0 release
Hi everyone, as we head into a new year full of optimism, is it time to start discussing the next major release? We released 8.0 on Jun 18, 2019, over 18 months ago. Since then we've switched to a gradle-based build. We have added vector-valued fields and an HNSW neighbor search algorithm for them. At the same time Solr has been getting a major overhaul which should justify a release, I think? IIRC there was talk of making 9.0 be the first release of Solr as its own TLP. Is it time to start planning for that now? -Mike - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene Query Parser Syntax Specification
I'd like to engage someone to develop a stand-alone GUI for a Lucene database. I'm thinking something on the order of Luke but simpler and more tailored to the database itself. It is a database of US patents since 1976. If you know of someone who might be interested would you kindly have them get in touch with me (sguth...@gmail.com) or send along their contact information. Many thanks for your consideration. Apologies if this posting violates the list's guidelines. Cheers, Scott - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Lucene] Add javadoc for Lucene86PointsFormat class
You now have access. Sorry for the delay! ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Dec 23, 2020 at 8:44 PM LuXugang wrote: > Thanks David > > My userId is luxugang > > > > On Dec 23, 2020, at 21:31, David Smiley wrote: > > Please register at the ASF's Confluence / wiki space. Then tell me your > userId, and I will then grant you permissions to edit our wiki. > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Wed, Dec 23, 2020 at 2:50 AM LuXugang > wrote: > >> Hi, David >> >> Here the link on my personal website to introduce index file >> .kdd&.kdi：https:// >> www.amazingkoala.com.cn/Lucene_Document/IndexFile/2020/1104/175.html >> >> If it’s ok, I would like to rewrite it on >> https://cwiki.apache.org/confluence/display/LUCENE/Home, but I have no >> permission to edit. >> >> Jira link: https://issues.apache.org/jira/browse/LUCENE-9590?filter=-2 >> >> Actually, I have wrote some other articles to introduce Lucene but with >> Chinese, so if it is needed, I would like to write more in English. >> >> >> >> 2020年10月30日 16:57，LuXugang 写道： >> >> Thanks David, add link in javadocs is great, got it ~ >> >> On Oct 30, 2020, at 12:45 PM, David Smiley wrote: >> >> Fantastic contribution! >> >> I don't think we have images in our javadocs, but if you can prove me >> wrong then great! We could link to it from javadocs and host it at the >> Confluence based wiki here: >> https://cwiki.apache.org/confluence/display/LUCENE/Home >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Wed, Oct 28, 2020 at 11:39 AM LuXugang >> wrote: >> >>> Hi, >>> >>> I would like to add javadoc for Lucene86PointsFormat class, it is >>> really helpful for source reader to understand the data structure with >>> point value >>> >>> The attachment list part of the data structure （filled with color means >>> it has sub data structure）<1.png> >>> >>> >>> >> >> >
