lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Singh <rahul.xavier.si...@gmail.com>
Subject Re: parent/child rows in solr
Date Thu, 13 Sep 2018 10:02:56 GMT
What’s your SLA? It seems that you have two problems - finding correlated information that’s
in a hierarchy and potentially displaying it.

I feel your desire to conflate the two is forcing you down a specific path. Often times in
complex scenarios I’ve found that an index like Solr is better for the search and not necessarily
the storage or display.

The question I have is : what’s your application workflow? Who is querying this data? How
are they expecting to see it? How fast do they need that data?

I understand what you’ve described (which seems to be a non functional requirement ) of
what you want to do but in order to help it would be helpful for me at least to know how the
data is ingested,
Enhanced, and retrieved.

In terms of data volume, you may consider indexing all data , but not storing all of it. This
makes sure you aren’t duplicating data that isn’t an awful waste of space.

Rahul Singh
Chief Executive Officer
m 202.905.2818

Anant Corporation
1010 Wisconsin Ave NW, Suite 250
Washington, D.C. 20007

We build and manage digital business technology platforms.
On Sep 11, 2018, 11:23 PM -0400, John Smith <localdevjs@gmail.com>, wrote:
> On Tue, Sep 11, 2018 at 11:05 PM Walter Underwood <wunder@wunderwood.org>
> wrote:
>
> > Have you tried modeling it with multivalued fields?
> >
> >
> That's an interesting idea, but I don't think that would work. We would
> lose the concept of "rows". So let's say child1 has col "a" and col "b",
> both are turned into multi-value fields in the solr index. Normally in sql
> we can query for a specific value in col "a", and then see what the
> associated value in col "b" would be, but we can't do that if we stuff the
> col values in multi-value; we can no longer see which value from col "a"
> corresponds to which value in col "b". I'm probably explaining that poorly,
> but I just don't see how that would work.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message