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

[Taewoo Kim]

Agreed.

Best,
Taewoo

On Fri, Jul 14, 2017 at 4:09 PM, Yingyi Bu  wrote:

> >> When we are encounter a field (“nested”) for which the is no
> compile-time information
> >> we should assume that the type of this field is completely open, i.e.,
> {}, and pass it down the chain.
>
> Correct, since it's enforced.
> The augmented enforced type maps should be recursively added into those
> nested ARecordType.
>
> Best,
> Yingyi
>
>
> On Fri, Jul 14, 2017 at 12:13 AM, Ildar Absalyamov <
> ildar.absalya...@gmail.com> wrote:
>
> > However, there should be a way to deal with this issue when the top-level
> > type is open.
> >
> > create type DBLPType as open {id: int32}
> > create index title_index_DBLP on DBLP(nested.one.title: string?)
> enforced;
> >
> > When we are encounter a field (“nested”) for which the is no compile-time
> > information we should assume that the type of this field is completely
> > open, i.e., {}, and pass it down the chain.
> >
> > > On Jul 14, 2017, at 00:09, Ildar Absalyamov <
> ildar.absalya...@gmail.com>
> > wrote:
> > >
> > > Taewoo,
> > >
> > > You’ve correctly identified the issue here: to make use of an enforced
> > index we must cast the record to a particular type, which is imposed by
> the
> > index.
> > >
> > > So, using your example, if we have an index on path “nested.one.title”
> > the indexed record must be castable to {…, “nested”: {…,”one”:
> {…,”title”:
> > string, …}, ...},…}.
> > > As you have observed a case when there is no “nested” field in the
> > top-level type leads to exception, because it relies of a fact that there
> > is a compile-time type information for a field “nested”. This type
> > information is used to build a type for aforementioned cast operator.
> > > Form the perspective of current implementation a runtime exception is a
> > bug, instead it should have caught this issue during compile time.
> > >
> > >> On Jul 13, 2017, at 23:10, Taewoo Kim  wrote:
> > >>
> > >> @Yingyi: thanks.
> > >>
> > >> @Mike: Yeah. My problem is how to associate the field type
> information.
> > >> Ideally, the leaf level has the field to type hash map and the parent
> > of it
> > >> has that hashmap in its record type. And its parent needs to have the
> > >> necessary information to reach to this record type. If we don't need
> any
> > >> pre-defined type at each level to create a multi-level enforced index,
> > then
> > >> things will become more complex to me. :-) Anyway, we can discuss
> > further
> > >> to finalize the field type propagation implementation.
> > >>
> > >> Best,
> > >> Taewoo
> > >>
> > >> On Thu, Jul 13, 2017 at 11:02 PM, Mike Carey 
> wrote:
> > >>
> > >>> Taewoo,
> > >>>
> > >>> To clarify further what should work:
> > >>> - We should support nested indexes that go down multiple levels.
> > >>> - We should (ideally) support their use in index-NL joins.
> > >>>
> > >>> Reflecting on our earlier conversation(s), I think I can see why
> you're
> > >>> asking this. :-) The augmented type information that'll be needed to
> do
> > >>> this completely/properly will actually have to associate types with
> > field
> > >>> paths (not just with fields by name) - which is a slightly more
> > complicated
> > >>> association.
> > >>>
> > >>> Cheers,
> > >>> Mike
> > >>>
> > >>>
> > >>> On 7/13/17 10:54 PM, Yingyi Bu wrote:
> > >>>
> >  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:
> > 
> >  @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
> > > the
> > > second one (with an index) should succeed?
> > >
> > > Best,
> > > Taewoo
> > >
> > > On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu 
> > wrote:
> > >
> > > 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 current index access
> > 
> > >>> method.
> > >
> > >> I
> > >>
> > >>> am encountering an issue with an open-type enforced index. 

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

[Yingyi Bu]

>> When we are encounter a field (“nested”) for which the is no
compile-time information
>> we should assume that the type of this field is completely open, i.e.,
{}, and pass it down the chain.

Correct, since it's enforced.
The augmented enforced type maps should be recursively added into those
nested ARecordType.

Best,
Yingyi


On Fri, Jul 14, 2017 at 12:13 AM, Ildar Absalyamov <
ildar.absalya...@gmail.com> wrote:

> However, there should be a way to deal with this issue when the top-level
> type is open.
>
> create type DBLPType as open {id: int32}
> create index title_index_DBLP on DBLP(nested.one.title: string?) enforced;
>
> When we are encounter a field (“nested”) for which the is no compile-time
> information we should assume that the type of this field is completely
> open, i.e., {}, and pass it down the chain.
>
> > On Jul 14, 2017, at 00:09, Ildar Absalyamov 
> wrote:
> >
> > Taewoo,
> >
> > You’ve correctly identified the issue here: to make use of an enforced
> index we must cast the record to a particular type, which is imposed by the
> index.
> >
> > So, using your example, if we have an index on path “nested.one.title”
> the indexed record must be castable to {…, “nested”: {…,”one”: {…,”title”:
> string, …}, ...},…}.
> > As you have observed a case when there is no “nested” field in the
> top-level type leads to exception, because it relies of a fact that there
> is a compile-time type information for a field “nested”. This type
> information is used to build a type for aforementioned cast operator.
> > Form the perspective of current implementation a runtime exception is a
> bug, instead it should have caught this issue during compile time.
> >
> >> On Jul 13, 2017, at 23:10, Taewoo Kim  wrote:
> >>
> >> @Yingyi: thanks.
> >>
> >> @Mike: Yeah. My problem is how to associate the field type information.
> >> Ideally, the leaf level has the field to type hash map and the parent
> of it
> >> has that hashmap in its record type. And its parent needs to have the
> >> necessary information to reach to this record type. If we don't need any
> >> pre-defined type at each level to create a multi-level enforced index,
> then
> >> things will become more complex to me. :-) Anyway, we can discuss
> further
> >> to finalize the field type propagation implementation.
> >>
> >> Best,
> >> Taewoo
> >>
> >> On Thu, Jul 13, 2017 at 11:02 PM, Mike Carey  wrote:
> >>
> >>> Taewoo,
> >>>
> >>> To clarify further what should work:
> >>> - We should support nested indexes that go down multiple levels.
> >>> - We should (ideally) support their use in index-NL joins.
> >>>
> >>> Reflecting on our earlier conversation(s), I think I can see why you're
> >>> asking this. :-) The augmented type information that'll be needed to do
> >>> this completely/properly will actually have to associate types with
> field
> >>> paths (not just with fields by name) - which is a slightly more
> complicated
> >>> association.
> >>>
> >>> Cheers,
> >>> Mike
> >>>
> >>>
> >>> On 7/13/17 10:54 PM, Yingyi Bu wrote:
> >>>
>  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:
> 
>  @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
> > the
> > second one (with an index) should succeed?
> >
> > Best,
> > Taewoo
> >
> > On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu 
> wrote:
> >
> > 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 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 enforced-index on a completely schemaless nested field. For
> 
> >>> example,
> >
> >> the
>  following doesn't generate any issue.
> 
>  //
>  create type 

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

[Taewoo Kim]

@Ildar: Yes. The current implementation requires that. So, I asked whether
which one makes sense.

Best,
Taewoo

On Fri, Jul 14, 2017 at 12:09 AM, Ildar Absalyamov <
ildar.absalya...@gmail.com> wrote:

> Taewoo,
>
> You’ve correctly identified the issue here: to make use of an enforced
> index we must cast the record to a particular type, which is imposed by the
> index.
>
> So, using your example, if we have an index on path “nested.one.title” the
> indexed record must be castable to {…, “nested”: {…,”one”: {…,”title”:
> string, …}, ...},…}.
> As you have observed a case when there is no “nested” field in the
> top-level type leads to exception, because it relies of a fact that there
> is a compile-time type information for a field “nested”. This type
> information is used to build a type for aforementioned cast operator.
> Form the perspective of current implementation a runtime exception is a
> bug, instead it should have caught this issue during compile time.
>
> > On Jul 13, 2017, at 23:10, Taewoo Kim  wrote:
> >
> > @Yingyi: thanks.
> >
> > @Mike: Yeah. My problem is how to associate the field type information.
> > Ideally, the leaf level has the field to type hash map and the parent of
> it
> > has that hashmap in its record type. And its parent needs to have the
> > necessary information to reach to this record type. If we don't need any
> > pre-defined type at each level to create a multi-level enforced index,
> then
> > things will become more complex to me. :-) Anyway, we can discuss further
> > to finalize the field type propagation implementation.
> >
> > Best,
> > Taewoo
> >
> > On Thu, Jul 13, 2017 at 11:02 PM, Mike Carey  wrote:
> >
> >> Taewoo,
> >>
> >> To clarify further what should work:
> >> - We should support nested indexes that go down multiple levels.
> >> - We should (ideally) support their use in index-NL joins.
> >>
> >> Reflecting on our earlier conversation(s), I think I can see why you're
> >> asking this. :-) The augmented type information that'll be needed to do
> >> this completely/properly will actually have to associate types with
> field
> >> paths (not just with fields by name) - which is a slightly more
> complicated
> >> association.
> >>
> >> Cheers,
> >> Mike
> >>
> >>
> >> On 7/13/17 10:54 PM, Yingyi Bu wrote:
> >>
> >>> 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:
> >>>
> >>> @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
>  the
>  second one (with an index) should succeed?
> 
>  Best,
>  Taewoo
> 
>  On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu 
> wrote:
> 
>  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 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 enforced-index on a completely schemaless nested field. For
> >>>
> >> example,
> 
> > the
> >>> following doesn't generate any issue.
> >>>
> >>> //
> >>> create type DBLPType as open {id: int32}
> >>> create type CSXType as closed {id: int32}
> >>>
> >>> create dataset DBLP(DBLPType) primary key id;
> >>> create dataset CSX(CSXType) primary key id;
> >>>
> >>> for $a in dataset('DBLP')
> >>> for $b in dataset('CSX')
> >>> where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
> >>> return {"arec": $a, "brec": $b}
> >>> //
> >>>
> >>> However, the following generates an exception. So, can we assume
> that
> >>>
> >> to
> 
> > create an enforced-index, except the leaf level, there should be a
> >>>
> >> defined
> >
> >> record type. For example, for this example, there should be "nested"
> >>>
> >> type
> >
> >> and "one" type.
> >>>
> >>> //
> >>> create type DBLPType as open {id: 

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

[Taewoo Kim]

@Ildar: you can change "create type CSXType as closed {id: int32}" to "create
type CSXType as *open* {id: int32}". My intention was that.


Best,
Taewoo

On Fri, Jul 14, 2017 at 12:06 AM, Ildar Absalyamov <
ildar.absalya...@gmail.com> wrote:

> Maybe I missed something, but how nested access on a closed type without a
> proper nested field is ever valid?
>
> create type CSXType as closed {id: int32}
> create index title_index_CSX on CSX(nested.one.title: string?) enforced;
>
> Will this index every be anything but empty?
>
> for $a in dataset('DBLP')
> for $b in dataset('CSX')
> where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
> return {"arec": $a, "brec": $b}
>
> Will this query return anything, but empty result?
>
> To me it feels like that should be compile time error in both cases:
> during index DDL and during the query.
>
> > On Jul 13, 2017, at 22:51, Taewoo Kim  wrote:
> >
> > @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
> the
> > second one (with an index) should succeed?
> >
> > Best,
> > Taewoo
> >
> > On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu  wrote:
> >
> >> 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 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 enforced-index on a completely schemaless nested field. For
> example,
>  the
>  following doesn't generate any issue.
> 
>  //
>  create type DBLPType as open {id: int32}
>  create type CSXType as closed {id: int32}
> 
>  create dataset DBLP(DBLPType) primary key id;
>  create dataset CSX(CSXType) primary key id;
> 
>  for $a in dataset('DBLP')
>  for $b in dataset('CSX')
>  where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
>  return {"arec": $a, "brec": $b}
>  //
> 
>  However, the following generates an exception. So, can we assume that
> to
>  create an enforced-index, except the leaf level, there should be a
> >> defined
>  record type. For example, for this example, there should be "nested"
> >> type
>  and "one" type.
> 
>  //
>  create type DBLPType as open {id: int32}
>  create type CSXType as closed {id: int32}
> 
>  create dataset DBLP(DBLPType) primary key id;
>  create dataset CSX(CSXType) primary key id;
> 
>  create index title_index_DBLP on DBLP(nested.one.title: string?)
> >> enforced;
>  create index title_index_CSX on CSX(nested.one.title: string?)
> enforced;
> 
>  for $a in dataset('DBLP')
>  for $b in dataset('CSX')
>  where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
>  return {"arec": $a, "brec": $b}
>  //
> 
>  Best,
>  Taewoo
> 
> 
> >>>
> >>
>
> Best regards,
> Ildar
>
>

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

[Ildar Absalyamov]

However, there should be a way to deal with this issue when the top-level type 
is open.

create type DBLPType as open {id: int32}
create index title_index_DBLP on DBLP(nested.one.title: string?) enforced;

When we are encounter a field (“nested”) for which the is no compile-time 
information we should assume that the type of this field is completely open, 
i.e., {}, and pass it down the chain.

> On Jul 14, 2017, at 00:09, Ildar Absalyamov  
> wrote:
> 
> Taewoo,
> 
> You’ve correctly identified the issue here: to make use of an enforced index 
> we must cast the record to a particular type, which is imposed by the index.
> 
> So, using your example, if we have an index on path “nested.one.title” the 
> indexed record must be castable to {…, “nested”: {…,”one”: {…,”title”: 
> string, …}, ...},…}.
> As you have observed a case when there is no “nested” field in the top-level 
> type leads to exception, because it relies of a fact that there is a 
> compile-time type information for a field “nested”. This type information is 
> used to build a type for aforementioned cast operator.
> Form the perspective of current implementation a runtime exception is a bug, 
> instead it should have caught this issue during compile time.
> 
>> On Jul 13, 2017, at 23:10, Taewoo Kim  wrote:
>> 
>> @Yingyi: thanks.
>> 
>> @Mike: Yeah. My problem is how to associate the field type information.
>> Ideally, the leaf level has the field to type hash map and the parent of it
>> has that hashmap in its record type. And its parent needs to have the
>> necessary information to reach to this record type. If we don't need any
>> pre-defined type at each level to create a multi-level enforced index, then
>> things will become more complex to me. :-) Anyway, we can discuss further
>> to finalize the field type propagation implementation.
>> 
>> Best,
>> Taewoo
>> 
>> On Thu, Jul 13, 2017 at 11:02 PM, Mike Carey  wrote:
>> 
>>> Taewoo,
>>> 
>>> To clarify further what should work:
>>> - We should support nested indexes that go down multiple levels.
>>> - We should (ideally) support their use in index-NL joins.
>>> 
>>> Reflecting on our earlier conversation(s), I think I can see why you're
>>> asking this. :-) The augmented type information that'll be needed to do
>>> this completely/properly will actually have to associate types with field
>>> paths (not just with fields by name) - which is a slightly more complicated
>>> association.
>>> 
>>> Cheers,
>>> Mike
>>> 
>>> 
>>> On 7/13/17 10:54 PM, Yingyi Bu wrote:
>>> 
 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:
 
 @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
> the
> second one (with an index) should succeed?
> 
> Best,
> Taewoo
> 
> On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu  wrote:
> 
> 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 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 enforced-index on a completely schemaless nested field. For
 
>>> example,
> 
>> the
 following doesn't generate any issue.
 
 //
 create type DBLPType as open {id: int32}
 create type CSXType as closed {id: int32}
 
 create dataset DBLP(DBLPType) primary key id;
 create dataset CSX(CSXType) primary key id;
 
 for $a in dataset('DBLP')
 for $b in dataset('CSX')
 where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
 return {"arec": $a, "brec": $b}
 //
 
 However, the following generates an exception. So, can we assume that
 
>>> to
> 
>> create an enforced-index, except the leaf level, there should be a
 
>>> defined
>> 
>>> 

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

[Ildar Absalyamov]

Taewoo,

You’ve correctly identified the issue here: to make use of an enforced index we 
must cast the record to a particular type, which is imposed by the index.

So, using your example, if we have an index on path “nested.one.title” the 
indexed record must be castable to {…, “nested”: {…,”one”: {…,”title”: string, 
…}, ...},…}.
As you have observed a case when there is no “nested” field in the top-level 
type leads to exception, because it relies of a fact that there is a 
compile-time type information for a field “nested”. This type information is 
used to build a type for aforementioned cast operator.
Form the perspective of current implementation a runtime exception is a bug, 
instead it should have caught this issue during compile time.

> On Jul 13, 2017, at 23:10, Taewoo Kim  wrote:
> 
> @Yingyi: thanks.
> 
> @Mike: Yeah. My problem is how to associate the field type information.
> Ideally, the leaf level has the field to type hash map and the parent of it
> has that hashmap in its record type. And its parent needs to have the
> necessary information to reach to this record type. If we don't need any
> pre-defined type at each level to create a multi-level enforced index, then
> things will become more complex to me. :-) Anyway, we can discuss further
> to finalize the field type propagation implementation.
> 
> Best,
> Taewoo
> 
> On Thu, Jul 13, 2017 at 11:02 PM, Mike Carey  wrote:
> 
>> Taewoo,
>> 
>> To clarify further what should work:
>> - We should support nested indexes that go down multiple levels.
>> - We should (ideally) support their use in index-NL joins.
>> 
>> Reflecting on our earlier conversation(s), I think I can see why you're
>> asking this. :-) The augmented type information that'll be needed to do
>> this completely/properly will actually have to associate types with field
>> paths (not just with fields by name) - which is a slightly more complicated
>> association.
>> 
>> Cheers,
>> Mike
>> 
>> 
>> On 7/13/17 10:54 PM, Yingyi Bu wrote:
>> 
>>> 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:
>>> 
>>> @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
 the
 second one (with an index) should succeed?
 
 Best,
 Taewoo
 
 On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu  wrote:
 
 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 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 enforced-index on a completely schemaless nested field. For
>>> 
>> example,
 
> the
>>> following doesn't generate any issue.
>>> 
>>> //
>>> create type DBLPType as open {id: int32}
>>> create type CSXType as closed {id: int32}
>>> 
>>> create dataset DBLP(DBLPType) primary key id;
>>> create dataset CSX(CSXType) primary key id;
>>> 
>>> for $a in dataset('DBLP')
>>> for $b in dataset('CSX')
>>> where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
>>> return {"arec": $a, "brec": $b}
>>> //
>>> 
>>> However, the following generates an exception. So, can we assume that
>>> 
>> to
 
> create an enforced-index, except the leaf level, there should be a
>>> 
>> defined
> 
>> record type. For example, for this example, there should be "nested"
>>> 
>> type
> 
>> and "one" type.
>>> 
>>> //
>>> create type DBLPType as open {id: int32}
>>> create type CSXType as closed {id: int32}
>>> 
>>> create dataset DBLP(DBLPType) primary key id;
>>> create dataset CSX(CSXType) primary key id;
>>> 
>>> create index title_index_DBLP on DBLP(nested.one.title: string?)
>>> 
>> enforced;
> 
>> create index title_index_CSX on CSX(nested.one.title: string?)
>>> 
>> enforced;
 
> for $a in dataset('DBLP')
>>> for $b in dataset('CSX')

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

[Ildar Absalyamov]

Maybe I missed something, but how nested access on a closed type without a 
proper nested field is ever valid?

create type CSXType as closed {id: int32}
create index title_index_CSX on CSX(nested.one.title: string?) enforced;

Will this index every be anything but empty?

for $a in dataset('DBLP')
for $b in dataset('CSX')
where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
return {"arec": $a, "brec": $b}

Will this query return anything, but empty result?

To me it feels like that should be compile time error in both cases: during 
index DDL and during the query.

> On Jul 13, 2017, at 22:51, Taewoo Kim  wrote:
> 
> @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 the
> second one (with an index) should succeed?
> 
> Best,
> Taewoo
> 
> On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu  wrote:
> 
>> 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 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 enforced-index on a completely schemaless nested field. For example,
 the
 following doesn't generate any issue.
 
 //
 create type DBLPType as open {id: int32}
 create type CSXType as closed {id: int32}
 
 create dataset DBLP(DBLPType) primary key id;
 create dataset CSX(CSXType) primary key id;
 
 for $a in dataset('DBLP')
 for $b in dataset('CSX')
 where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
 return {"arec": $a, "brec": $b}
 //
 
 However, the following generates an exception. So, can we assume that to
 create an enforced-index, except the leaf level, there should be a
>> defined
 record type. For example, for this example, there should be "nested"
>> type
 and "one" type.
 
 //
 create type DBLPType as open {id: int32}
 create type CSXType as closed {id: int32}
 
 create dataset DBLP(DBLPType) primary key id;
 create dataset CSX(CSXType) primary key id;
 
 create index title_index_DBLP on DBLP(nested.one.title: string?)
>> enforced;
 create index title_index_CSX on CSX(nested.one.title: string?) enforced;
 
 for $a in dataset('DBLP')
 for $b in dataset('CSX')
 where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
 return {"arec": $a, "brec": $b}
 //
 
 Best,
 Taewoo
 
 
>>> 
>> 

Best regards,
Ildar

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

[Mike Carey]

Note that indexes can ONLY be associated with datasets - so it would 
seem (w/o looking at the code :-)) that maybe the required info could be 
hung at the top level in (path, type) form as an extension of the 
dataset's top-level record type.  E.g., given something like


CREATE DATASET ChirpMessages(ChirpMessageType) PRIMARY KEY chirpId;

CREATE INDEX ScreenNameIndex ON ChirpMessages(user.screenName: 
string?) TYPE BTREE ENFORCED;


then you would return a dataset type descriptor that says that 
ChirpMessages has all the info of type ChirpMessageType augmented with 
an additional typed path user.screenName of data type string.


Just a thought (probably half-baked :-))...

Cheers,

Mike


On 7/13/17 11:10 PM, Taewoo Kim wrote:

@Yingyi: thanks.

@Mike: Yeah. My problem is how to associate the field type information.
Ideally, the leaf level has the field to type hash map and the parent of it
has that hashmap in its record type. And its parent needs to have the
necessary information to reach to this record type. If we don't need any
pre-defined type at each level to create a multi-level enforced index, then
things will become more complex to me. :-) Anyway, we can discuss further
to finalize the field type propagation implementation.

Best,
Taewoo

On Thu, Jul 13, 2017 at 11:02 PM, Mike Carey  wrote:


Taewoo,

To clarify further what should work:
  - We should support nested indexes that go down multiple levels.
  - We should (ideally) support their use in index-NL joins.

Reflecting on our earlier conversation(s), I think I can see why you're
asking this. :-) The augmented type information that'll be needed to do
this completely/properly will actually have to associate types with field
paths (not just with fields by name) - which is a slightly more complicated
association.

Cheers,
Mike


On 7/13/17 10:54 PM, Yingyi Bu wrote:


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:

@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
the
second one (with an index) should succeed?

Best,
Taewoo

On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu  wrote:

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 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 enforced-index on a completely schemaless nested field. For
example,

the

following doesn't generate any issue.

//
create type DBLPType as open {id: int32}
create type CSXType as closed {id: int32}

create dataset DBLP(DBLPType) primary key id;
create dataset CSX(CSXType) primary key id;

for $a in dataset('DBLP')
for $b in dataset('CSX')
where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
return {"arec": $a, "brec": $b}
//

However, the following generates an exception. So, can we assume that


to

create an enforced-index, except the leaf level, there should be a

defined
record type. For example, for this example, there should be "nested"
type
and "one" type.

//
create type DBLPType as open {id: int32}
create type CSXType as closed {id: int32}

create dataset DBLP(DBLPType) primary key id;
create dataset CSX(CSXType) primary key id;

create index title_index_DBLP on DBLP(nested.one.title: string?)


enforced;
create index title_index_CSX on CSX(nested.one.title: string?)
enforced;

for $a in dataset('DBLP')

for $b in dataset('CSX')
where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
return {"arec": $a, "brec": $b}
//

Best,
Taewoo

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

[Taewoo Kim]

@Yingyi: thanks.

@Mike: Yeah. My problem is how to associate the field type information.
Ideally, the leaf level has the field to type hash map and the parent of it
has that hashmap in its record type. And its parent needs to have the
necessary information to reach to this record type. If we don't need any
pre-defined type at each level to create a multi-level enforced index, then
things will become more complex to me. :-) Anyway, we can discuss further
to finalize the field type propagation implementation.

Best,
Taewoo

On Thu, Jul 13, 2017 at 11:02 PM, Mike Carey  wrote:

> Taewoo,
>
> To clarify further what should work:
>  - We should support nested indexes that go down multiple levels.
>  - We should (ideally) support their use in index-NL joins.
>
> Reflecting on our earlier conversation(s), I think I can see why you're
> asking this. :-) The augmented type information that'll be needed to do
> this completely/properly will actually have to associate types with field
> paths (not just with fields by name) - which is a slightly more complicated
> association.
>
> Cheers,
> Mike
>
>
> On 7/13/17 10:54 PM, Yingyi Bu wrote:
>
>> 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:
>>
>> @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
>>> the
>>> second one (with an index) should succeed?
>>>
>>> Best,
>>> Taewoo
>>>
>>> On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu  wrote:
>>>
>>> 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 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 enforced-index on a completely schemaless nested field. For
>>
> example,
>>>
 the
>> following doesn't generate any issue.
>>
>> //
>> create type DBLPType as open {id: int32}
>> create type CSXType as closed {id: int32}
>>
>> create dataset DBLP(DBLPType) primary key id;
>> create dataset CSX(CSXType) primary key id;
>>
>> for $a in dataset('DBLP')
>> for $b in dataset('CSX')
>> where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
>> return {"arec": $a, "brec": $b}
>> //
>>
>> However, the following generates an exception. So, can we assume that
>>
> to
>>>
 create an enforced-index, except the leaf level, there should be a
>>
> defined

> record type. For example, for this example, there should be "nested"
>>
> type

> and "one" type.
>>
>> //
>> create type DBLPType as open {id: int32}
>> create type CSXType as closed {id: int32}
>>
>> create dataset DBLP(DBLPType) primary key id;
>> create dataset CSX(CSXType) primary key id;
>>
>> create index title_index_DBLP on DBLP(nested.one.title: string?)
>>
> enforced;

> create index title_index_CSX on CSX(nested.one.title: string?)
>>
> enforced;
>>>
 for $a in dataset('DBLP')
>> for $b in dataset('CSX')
>> where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
>> return {"arec": $a, "brec": $b}
>> //
>>
>> Best,
>> Taewoo
>>
>>
>>
>

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

[Mike Carey]

Taewoo,

To clarify further what should work:
 - We should support nested indexes that go down multiple levels.
 - We should (ideally) support their use in index-NL joins.

Reflecting on our earlier conversation(s), I think I can see why you're 
asking this. :-) The augmented type information that'll be needed to do 
this completely/properly will actually have to associate types with 
field paths (not just with fields by name) - which is a slightly more 
complicated association.


Cheers,
Mike

On 7/13/17 10:54 PM, Yingyi Bu wrote:

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:


@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 the
second one (with an index) should succeed?

Best,
Taewoo

On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu  wrote:


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 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 enforced-index on a completely schemaless nested field. For

example,

the
following doesn't generate any issue.

//
create type DBLPType as open {id: int32}
create type CSXType as closed {id: int32}

create dataset DBLP(DBLPType) primary key id;
create dataset CSX(CSXType) primary key id;

for $a in dataset('DBLP')
for $b in dataset('CSX')
where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
return {"arec": $a, "brec": $b}
//

However, the following generates an exception. So, can we assume that

to

create an enforced-index, except the leaf level, there should be a

defined

record type. For example, for this example, there should be "nested"

type

and "one" type.

//
create type DBLPType as open {id: int32}
create type CSXType as closed {id: int32}

create dataset DBLP(DBLPType) primary key id;
create dataset CSX(CSXType) primary key id;

create index title_index_DBLP on DBLP(nested.one.title: string?)

enforced;

create index title_index_CSX on CSX(nested.one.title: string?)

enforced;

for $a in dataset('DBLP')
for $b in dataset('CSX')
where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
return {"arec": $a, "brec": $b}
//

Best,
Taewoo

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

[Yingyi Bu]

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:

> @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 the
> second one (with an index) should succeed?
>
> Best,
> Taewoo
>
> On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu  wrote:
>
> > 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 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 enforced-index on a completely schemaless nested field. For
> example,
> > >> the
> > >> following doesn't generate any issue.
> > >>
> > >> //
> > >> create type DBLPType as open {id: int32}
> > >> create type CSXType as closed {id: int32}
> > >>
> > >> create dataset DBLP(DBLPType) primary key id;
> > >> create dataset CSX(CSXType) primary key id;
> > >>
> > >> for $a in dataset('DBLP')
> > >> for $b in dataset('CSX')
> > >> where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
> > >> return {"arec": $a, "brec": $b}
> > >> //
> > >>
> > >> However, the following generates an exception. So, can we assume that
> to
> > >> create an enforced-index, except the leaf level, there should be a
> > defined
> > >> record type. For example, for this example, there should be "nested"
> > type
> > >> and "one" type.
> > >>
> > >> //
> > >> create type DBLPType as open {id: int32}
> > >> create type CSXType as closed {id: int32}
> > >>
> > >> create dataset DBLP(DBLPType) primary key id;
> > >> create dataset CSX(CSXType) primary key id;
> > >>
> > >> create index title_index_DBLP on DBLP(nested.one.title: string?)
> > enforced;
> > >> create index title_index_CSX on CSX(nested.one.title: string?)
> enforced;
> > >>
> > >> for $a in dataset('DBLP')
> > >> for $b in dataset('CSX')
> > >> where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
> > >> return {"arec": $a, "brec": $b}
> > >> //
> > >>
> > >> Best,
> > >> Taewoo
> > >>
> > >>
> > >
> >
>

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

[Taewoo Kim]

@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 the
second one (with an index) should succeed?

Best,
Taewoo

On Thu, Jul 13, 2017 at 9:58 PM, Yingyi Bu  wrote:

> 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 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 enforced-index on a completely schemaless nested field. For example,
> >> the
> >> following doesn't generate any issue.
> >>
> >> //
> >> create type DBLPType as open {id: int32}
> >> create type CSXType as closed {id: int32}
> >>
> >> create dataset DBLP(DBLPType) primary key id;
> >> create dataset CSX(CSXType) primary key id;
> >>
> >> for $a in dataset('DBLP')
> >> for $b in dataset('CSX')
> >> where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
> >> return {"arec": $a, "brec": $b}
> >> //
> >>
> >> However, the following generates an exception. So, can we assume that to
> >> create an enforced-index, except the leaf level, there should be a
> defined
> >> record type. For example, for this example, there should be "nested"
> type
> >> and "one" type.
> >>
> >> //
> >> create type DBLPType as open {id: int32}
> >> create type CSXType as closed {id: int32}
> >>
> >> create dataset DBLP(DBLPType) primary key id;
> >> create dataset CSX(CSXType) primary key id;
> >>
> >> create index title_index_DBLP on DBLP(nested.one.title: string?)
> enforced;
> >> create index title_index_CSX on CSX(nested.one.title: string?) enforced;
> >>
> >> for $a in dataset('DBLP')
> >> for $b in dataset('CSX')
> >> where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
> >> return {"arec": $a, "brec": $b}
> >> //
> >>
> >> Best,
> >> Taewoo
> >>
> >>
> >
>

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

[Yingyi Bu]

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 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 enforced-index on a completely schemaless nested field. For example,
>> the
>> following doesn't generate any issue.
>>
>> //
>> create type DBLPType as open {id: int32}
>> create type CSXType as closed {id: int32}
>>
>> create dataset DBLP(DBLPType) primary key id;
>> create dataset CSX(CSXType) primary key id;
>>
>> for $a in dataset('DBLP')
>> for $b in dataset('CSX')
>> where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
>> return {"arec": $a, "brec": $b}
>> //
>>
>> However, the following generates an exception. So, can we assume that to
>> create an enforced-index, except the leaf level, there should be a defined
>> record type. For example, for this example, there should be "nested" type
>> and "one" type.
>>
>> //
>> create type DBLPType as open {id: int32}
>> create type CSXType as closed {id: int32}
>>
>> create dataset DBLP(DBLPType) primary key id;
>> create dataset CSX(CSXType) primary key id;
>>
>> create index title_index_DBLP on DBLP(nested.one.title: string?) enforced;
>> create index title_index_CSX on CSX(nested.one.title: string?) enforced;
>>
>> for $a in dataset('DBLP')
>> for $b in dataset('CSX')
>> where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
>> return {"arec": $a, "brec": $b}
>> //
>>
>> Best,
>> Taewoo
>>
>>
>

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

[Mike Carey]

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 that my understanding is correct. It looks like we can't have
an enforced-index on a completely schemaless nested field. For example, the
following doesn't generate any issue.

//
create type DBLPType as open {id: int32}
create type CSXType as closed {id: int32}

create dataset DBLP(DBLPType) primary key id;
create dataset CSX(CSXType) primary key id;

for $a in dataset('DBLP')
for $b in dataset('CSX')
where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
return {"arec": $a, "brec": $b}
//

However, the following generates an exception. So, can we assume that to
create an enforced-index, except the leaf level, there should be a defined
record type. For example, for this example, there should be "nested" type
and "one" type.

//
create type DBLPType as open {id: int32}
create type CSXType as closed {id: int32}

create dataset DBLP(DBLPType) primary key id;
create dataset CSX(CSXType) primary key id;

create index title_index_DBLP on DBLP(nested.one.title: string?) enforced;
create index title_index_CSX on CSX(nested.one.title: string?) enforced;

for $a in dataset('DBLP')
for $b in dataset('CSX')
where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
return {"arec": $a, "brec": $b}
//

Best,
Taewoo

Nested type + open-enforced-index question.

[Taewoo Kim]

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 enforced-index on a completely schemaless nested field. For example, the
following doesn't generate any issue.

//
create type DBLPType as open {id: int32}
create type CSXType as closed {id: int32}

create dataset DBLP(DBLPType) primary key id;
create dataset CSX(CSXType) primary key id;

for $a in dataset('DBLP')
for $b in dataset('CSX')
where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
return {"arec": $a, "brec": $b}
//

However, the following generates an exception. So, can we assume that to
create an enforced-index, except the leaf level, there should be a defined
record type. For example, for this example, there should be "nested" type
and "one" type.

//
create type DBLPType as open {id: int32}
create type CSXType as closed {id: int32}

create dataset DBLP(DBLPType) primary key id;
create dataset CSX(CSXType) primary key id;

create index title_index_DBLP on DBLP(nested.one.title: string?) enforced;
create index title_index_CSX on CSX(nested.one.title: string?) enforced;

for $a in dataset('DBLP')
for $b in dataset('CSX')
where $a.nested.one.title /*+ indexnl */ = $b.nested.one.title
return {"arec": $a, "brec": $b}
//

Best,
Taewoo