Re: Nested type + open-enforced-index question.

Hi Taewoo, The first query shouldn't fail because indexnl is just a hint. The second query should succeed because it's a valid indexing statement. High nesting levels in open record like JSON is not uncommon. Best, Yingyi On Thu, Jul 13, 2017 at 10:51 PM, Taewoo Kim wrote:

Re: Nested type + open-enforced-index question.

@Mike: In order to properly deal with the enforced index on a nested-type field, I need to make sure that whether my understanding (each nested type (except the leaf level0 has a record type for the next level) is correct or not. Which one is a bug? The first one (without index) should fail? Or

Re: Nested type + open-enforced-index question.

Indeed, it's a bug! Best, Yingyi On Thu, Jul 13, 2017 at 9:52 PM, Mike Carey wrote: > Sounds like a bug to me. > > > > On 7/13/17 7:59 PM, Taewoo Kim wrote: > >> Currently, I am working on a field type propagation without using >> initializing the OptimizableSubTree in the

Re: Nested type + open-enforced-index question.

Sounds like a bug to me. On 7/13/17 7:59 PM, Taewoo Kim wrote: Currently, I am working on a field type propagation without using initializing the OptimizableSubTree in the current index access method. I am encountering an issue with an open-type enforced index. So, I just want to make sure

Nested type + open-enforced-index question.

Currently, I am working on a field type propagation without using initializing the OptimizableSubTree in the current index access method. I am encountering an issue with an open-type enforced index. So, I just want to make sure that my understanding is correct. It looks like we can't have an