I view “flattening” as moving from a highly functional format (JSON) to a less
functional format (flat, text-like).
Many of the less functional formats we see, that do not permit hierarchical
Maps, nevertheless permit List and List. (No, not List,
obviously.)
A typical, and workable, flattening
+1
On February 24, 2017 at 11:05:21, Nick Allen (n...@nickallen.org) wrote:
I'll just flatten maps like we do in the JSONMapParser and leave it at
that. I will not do anything with lists. We can clean this up as part of
METRON-735.
On Fri, Feb 24, 2017 at 11:00 AM, Otto Fowler
wrote:
> Tells
I'll just flatten maps like we do in the JSONMapParser and leave it at
that. I will not do anything with lists. We can clean this up as part of
METRON-735.
On Fri, Feb 24, 2017 at 11:00 AM, Otto Fowler
wrote:
> Tells you how much solr stuff we have going on.
> This is all yucky. Then again I v
Tells you how much solr stuff we have going on.
This is all yucky. Then again I voted for 1.
On February 24, 2017 at 10:26:52, Nick Allen (n...@nickallen.org) wrote:
So I don't need to unfold lists, but I do maps? I thought the commentary
on METRON-686 was that Solr cannot handle "complex ty
And sorry this should be...
"list": ["e1", "e2", "e3"]
->
list.0: e1
list.1: e2
list.2: e3
On Fri, Feb 24, 2017 at 10:26 AM, Nick Allen wrote:
> So I don't need to unfold lists, but I do maps? I thought the commentary
> on METRON-686 was that Solr cannot handle "complex types". I took that t
Again, I don't want to do it, if we don't have to, but it is definitely
possible, no?
A map embedded in a list like...
"list": [
"e1",
{
"k1": "v1",
"k2": "v2"
},
"e3"
]
would translate to..
list.0: e1
list.1.k1: v1
list.1.k2: v2
list.2: e3
On Fri, Feb
So I don't need to unfold lists, but I do maps? I thought the commentary
on METRON-686 was that Solr cannot handle "complex types". I took that to
mean both maps and lists.
Yes, Otto. The only reasonable way to unfold a list would be using the
index of the element.
"list": ["e1", "e2", "e3"]
-
I agree with this, flattening the map doesn’t change it’s meaning - it is
not arbitrary.
Finding an item still makes sense, what I mean is the flattened name is
meaningful.
What you would have to do for an array would make it not meaningful, since
it would just be an
arbitrary positional number i
No, I don’t think it does. I am not sure how you would do that, other than
putting a number at the end of the unwrapped array item?
On February 24, 2017 at 10:12:26, Nick Allen (n...@nickallen.org) wrote:
Per Otto's advice, I am looking to reuse the normalizer/flattener mechanism
that currentl
I don't know, I think I'm ok with lists, but I might be biased. I think
it's the nested maps that were the issue. Flattening lists seems...wrong
to me. Maybe that's wrong-headed, but there it is. ;)
On Fri, Feb 24, 2017 at 10:12 AM, Nick Allen wrote:
> Per Otto's advice, I am looking to reuse
Per Otto's advice, I am looking to reuse the normalizer/flattener mechanism
that currently exists in JSONMapParser. It looks like the mechanism is
built into the class, so I will have to extract it. It looks like landing
it in JSONUtils is a logical place.
It appears that the mechanism only hand
11 matches
Mail list logo
