Re: Avoiding single digit and single charcater ONLY query by putting them in stopwords list
Oh hi Mark! Why would you wanna do such a thing in the solr end. Imho it would be much more clean and easy to do it on the client side Regards, Konstantinos > On 27 Oct 2020, at 16:42, Mark Robinson wrote: > > Hello, > > I want to block queries having only a digit like "1" or "2" ,... or > just a letter like "a" or "b" ... > > Is it a good idea to block them ... ie just single digits 0 - 9 and a - z > by putting them as a stop word? The problem with this I can anticipate is a > query like "1 inch screw" can have the important information "1" stripped > out if I tokenize it. > > So what would be a good way to avoid single digit only and single letter > only queries, from the Solr end? > Or should I not do this at the Solr end at all? > > Could someone please share your thoughts? > > Thanks! > Mark == Konstantinos Koukouvis konstantinos.koukou...@mecenat.com Using Golang and Solr? Try this: https://github.com/mecenat/solr
Re: [EXT: NEWSLETTER] SolrDocument difference between String and text_general
Reindexing has to be done either by starting from scratch or by deleting all documents and then re-inserting them. Right? https://lucene.apache.org/solr/guide/8_0/reindexing.html <https://lucene.apache.org/solr/guide/8_0/reindexing.html> Regards, Konstantinos > On 20 Oct 2020, at 14:51, Erick Erickson wrote: > > You’re seeing consistent results here because you started with a _new_ > collection that had no old segments lying around. == Konstantinos Koukouvis konstantinos.koukou...@mecenat.com Using Golang and Solr? Try this: https://github.com/mecenat/solr
Re: SolrDocument difference between String and text_general
Hi Owen,
If I understand correctly you have changed the schema, then reloaded the core
and reindexed all data right? Cause whenever I got this error I’ve usually
forgotten to do one of those two things…
Regards,
Konstantinos
> On 20 Oct 2020, at 09:53, Cox, Owen wrote:
>
> Hi folks,
>
> I'm using Solr 8.5.2 and populating documents which include a string field
> called "title". This field used to be text_general, but the data was
> reindexed and we've been inserting data happily with REST calls and it's been
> behaving as desired.
>
> I've now written a Java Spring-Boot program to populate documents (snippet
> below) using SolrCrudRepository. This works when I don't index the "title"
> field, but when I try include title I get the following error "cannot change
> field "title" from index options=DOCS_AND_FREQS_AND_POSITIONS to inconsistent
> index options=DOCS"
>
> To me that looks like it's trying to index the title as text_general and
> store it in a string field. But the Solr schema states that field is string,
> all of the data in it is string, and any other string field in the document
> which is string is indexed correctly.
>
> Could there be any hanging reference to the field's type anywhere? Or some
> requirement that a field named "title" is always text_general or something
> odd like that?
>
> Any help appreciated, thanks
> Owen
>
>
>
> @Data
> @SolrDocument(collection="mycollection")
> public class Node {
>
>@Id
>@Field
>private String id;
>
>
>@Field
>private String title;
>
>
>
>
> IMPORTANT NOTICE
>
> This communication is from Deloitte LLP, a limited liability partnership
> registered in England and Wales with registered number OC303675. Its
> registered office is 1 New Street Square, London EC4A 3HQ, United Kingdom.
> Deloitte LLP is the United Kingdom affiliate of Deloitte NSE LLP, a member
> firm of Deloitte Touche Tohmatsu Limited, a UK private company limited by
> guarantee ("DTTL"). DTTL and each of its member firms are legally separate
> and independent entities. DTTL and Deloitte NSE LLP do not provide services
> to clients. Please see
> www.deloitte.co.uk/about<https://www.deloitte.co.uk/about> to learn more
> about our global network of member firms. For details of our professional
> regulation please see
> Regulators<https://www2.deloitte.com/uk/en/footerlinks1/regulators-and-provision-service-regulations.html>.
>
> This communication contains information which is confidential and may also be
> privileged. It is for the exclusive use of the intended recipient(s). If you
> are not the intended recipient(s), please notify
> it.security...@deloitte.co.uk<mailto:it.security...@deloitte.co.uk> and
> destroy this message immediately. Email communications cannot be guaranteed
> to be secure or free from error or viruses. All emails sent to or from a
> @deloitte.co.uk email account are securely archived and stored by an external
> supplier within the European Union.
>
> You can understand more about how we collect and use (process) your personal
> information in our Privacy
> Notice<https://www2.deloitte.com/uk/en/legal/privacy.html>.
>
> Deloitte LLP does not accept any liability for use of or reliance on the
> contents of this email by any person save by the intended recipient(s) to the
> extent agreed in a Deloitte LLP engagement contract.
>
> Opinions, conclusions and other information in this email which have not been
> delivered by way of the business of Deloitte LLP are neither given nor
> endorsed by it.
==
Konstantinos Koukouvis
konstantinos.koukou...@mecenat.com
Using Golang and Solr? Try this: https://github.com/mecenat/solr
Re: Improve results/relevance
Hi Jayadevan, There are a couple of ways to achieve the result you want! Two things you could do from the top of my head are: You could sort the results based on some field, or boost some fields so that they get a higher score. > On 17 Oct 2020, at 05:51, Jayadevan Maymala wrote: > > Hi all, > > We have a catalogue of many products, including smart phones. We use > *edismax* query parser. If someone types in iPhone 11, we are getting the > correct results. But iPhone 11 Pro is coming before iPhone 11. What options > can be used to improve this? > > Regards, > Jayadevan ====== Konstantinos Koukouvis konstantinos.koukou...@mecenat.com Using Golang and Solr? Try this: https://github.com/mecenat/solr
Re: Solr client
Had no idea about this! Thanks a lot Eric!! > On 4 Sep 2020, at 12:14, Eric Pugh wrote: > > Konstantinos, have you seen https://solr.cool/? It’s an aggregation site for > all the extensions to Solr. You can add your project there, and that should > get some more awareness! > > >> On Sep 2, 2020, at 2:21 AM, Konstantinos Koukouvis >> wrote: >> >> Hi everybody, sorry in advance if I’m using the mailing list wrong, this is >> the first time I’m attempting such a thing. >> >> To all you gophers out there we at Mecenat, have been working at a new solr >> client wrapper with focus on single solr instance usage, that supports the >> search API, schema API and core admin API. With this email I’m trying to >> raise awareness to the community, get some feedback by having more people to >> test every nook and cranny of it, so that we can improve our solution and >> hopefully help you find that client that makes using solr in go more >> intuitive and simple. >> >> Here’s the link, and thank you all for your time: >> https://github.com/mecenat/solr >> >> With regards, >> Konstantinos >> > > ___ > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com <http://www.opensourceconnections.com/> > | My Free/Busy <http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless of > whether attachments are marked as such. >
Solr client
Hi everybody, sorry in advance if I’m using the mailing list wrong, this is the first time I’m attempting such a thing. To all you gophers out there we at Mecenat, have been working at a new solr client wrapper with focus on single solr instance usage, that supports the search API, schema API and core admin API. With this email I’m trying to raise awareness to the community, get some feedback by having more people to test every nook and cranny of it, so that we can improve our solution and hopefully help you find that client that makes using solr in go more intuitive and simple. Here’s the link, and thank you all for your time: https://github.com/mecenat/solr With regards, Konstantinos
