Solr Usage Question

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Solr Usage Question

Samatha Sajja
Hi,

I have a use case where I am not sure which type of fields to use.

Use case: For every order line we would like to store statuses and quantities
For ex, I have placed an order with some item quantity of 6. 4 of them got shipped and 2 of them in processing. I would like to search on status and also need to know how much quantity is in that status

Our current data model is for every order line. In the above scenario an order line can have multiple statuses and multiple quantities in those statuses. Don’t want to duplicate the data as it will update the statuses and quantity very often.

Solution:  Thinking of having a status:[SHIPPED,PROCESSING] and status_quantity:{"SHIPPED":4,"PROCESSING":2}

Question: What is your recommendation? How should I define these fields?

Regards
Samatha Sajja
Staff Software Engineer - TechCA
Samsclub.com Engineering
Location: 860 -1st Floor
Email: [hidden email]<file:///[hidden email]>
Slack: ssajja

Reply | Threaded
Open this post in threaded view
|

Re: Solr Usage Question

Alexandre Rafalovitch
Your use case should not start from data stored, but from the queries
you want to search. Then you massage your data to fit that.

Don't worry too much about 'duplicate' too much at this stage. You
could delete the historical records if needed. Or index them without
storing.

What you should try to avoid is updating a record, as - under the
covers - a completely new record is created anyway. That's how the
search speed is achieved.

Regards,
   Alex.

On 12 September 2018 at 16:10, Samatha Sajja
<[hidden email]> wrote:

> Hi,
>
> I have a use case where I am not sure which type of fields to use.
>
> Use case: For every order line we would like to store statuses and quantities
> For ex, I have placed an order with some item quantity of 6. 4 of them got shipped and 2 of them in processing. I would like to search on status and also need to know how much quantity is in that status
>
> Our current data model is for every order line. In the above scenario an order line can have multiple statuses and multiple quantities in those statuses. Don’t want to duplicate the data as it will update the statuses and quantity very often.
>
> Solution:  Thinking of having a status:[SHIPPED,PROCESSING] and status_quantity:{"SHIPPED":4,"PROCESSING":2}
>
> Question: What is your recommendation? How should I define these fields?
>
> Regards
> Samatha Sajja
> Staff Software Engineer - TechCA
> Samsclub.com Engineering
> Location: 860 -1st Floor
> Email: [hidden email]<file:///[hidden email]>
> Slack: ssajja
>
Reply | Threaded
Open this post in threaded view
|

Re: Solr Usage Question

Walter Underwood
In reply to this post by Samatha Sajja
My recommendation is to put that data in a relational database. That does not look like an appropriate use for Solr.

wunder
Walter Underwood
[hidden email]
http://observer.wunderwood.org/  (my blog)

> On Sep 12, 2018, at 1:10 PM, Samatha Sajja <[hidden email]> wrote:
>
> Hi,
>
> I have a use case where I am not sure which type of fields to use.
>
> Use case: For every order line we would like to store statuses and quantities
> For ex, I have placed an order with some item quantity of 6. 4 of them got shipped and 2 of them in processing. I would like to search on status and also need to know how much quantity is in that status
>
> Our current data model is for every order line. In the above scenario an order line can have multiple statuses and multiple quantities in those statuses. Don’t want to duplicate the data as it will update the statuses and quantity very often.
>
> Solution:  Thinking of having a status:[SHIPPED,PROCESSING] and status_quantity:{"SHIPPED":4,"PROCESSING":2}
>
> Question: What is your recommendation? How should I define these fields?
>
> Regards
> Samatha Sajja
> Staff Software Engineer - TechCA
> Samsclub.com Engineering
> Location: 860 -1st Floor
> Email: [hidden email]<file:///[hidden email]>
> Slack: ssajja
>