check out the videos on this website TROO.TUBE don't be such a
sheep/zombie/loser/NPC. Much love!
https://troo.tube/videos/watch/aaa64864-52ee-4201-922f-41300032f219
On Tue, May 12, 2020 at 3:35 AM Jan Høydahl wrote:
>
> Note that my example is simplified. Both the parent and child docs need to
Note that my example is simplified. Both the parent and child docs need to have
globally unique ‘id’ fields, and any field names used both in parent and child
needs to have same fieldType in schema.
There was some plans to automatically generate IDs for child documents if they
do not exist, but
Thanks Jan! This helps a lot!
Sai Vignan Malyala
On Mon, May 11, 2020 at 5:07 PM Jan Høydahl wrote:
> Sounds like you are looking for parent/child docs here, see
> https://lucene.apache.org/solr/guide/8_5/indexing-nested-documents.html
>
> {
> "type": "user",
> "name": "user1",
Thank you Jan, Vincezo and Joe.
This helps us a lot.
On Mon, May 11, 2020 at 10:03 PM Joe Obernberger <
joseph.obernber...@gmail.com> wrote:
> Could you use a multi-valued field for user in each of your products?
>
> So productA and a field User that is a list of all the users that have
>
Could you use a multi-valued field for user in each of your products?
So productA and a field User that is a list of all the users that have
productA. Then you could do a search like:
user:User1 AND Product_A_cost:[5 TO 10]
user:(User1 User5...) AND Product_B_cost[0 TO 40]
-Joe
On
For in-place updates you should read this:
https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html
On Mon, May 11, 2020 at 2:49 PM Vincenzo D'Amore wrote:
> But keep in mind that "With the exception of in-place updates, the whole
> block must be updated or deleted together,
But keep in mind that "With the exception of in-place updates, the whole
block must be updated or deleted together, not separately. For some
applications this may result in tons of extra indexing and thus may be a
deal-breaker."
On Mon, May 11, 2020 at 1:37 PM Jan Høydahl wrote:
> Sounds like
Creating that many dynamic fields is a bad idea, Solr isn’t
built to handle that many fields. It works, but performance
will decline and I’d guess that this app is sensitive
to response time.
So try Jan’s approach or find another would be my advice.
Best,
Erick
> On May 11, 2020, at 7:37 AM,
Sounds like you are looking for parent/child docs here, see
https://lucene.apache.org/solr/guide/8_5/indexing-nested-documents.html
{
"type": "user",
"name": "user1",
"products": [
{ "id": "prod_A", "cost": 50},
{ "id": "prod_B", "cost":
I have around 1M products used by my clients.
Client need a filter of these 1M products by their cost filters.
Just like:
User1 has 5 products (A,B,C,D,E)
User2 has 3 products (D,E,F)
User3 has 10 products (A,B,C,H,I,J,K,L,M,N,O)
...every customer has different sets.
Now they want to search
Sounds like an anti pattern. Can you explain what search problem you are trying
to solve with this many unique fields?
Jan Høydahl
> 11. mai 2020 kl. 07:51 skrev Vignan Malyala :
>
> Hi
> Is it good idea to create 10 dynamic fields of time pint in solr?
> I have that many fields to search
Hi
Is it good idea to create 10 dynamic fields of time pint in solr?
I have that many fields to search on actually which come upon based on
users.
Thanks in advance!
And I'm using Solr Cloud in real-time.
Regards,
Sai Vignan M
12 matches
Mail list logo
