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.
>> 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
@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
@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
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
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”:
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
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
@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
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
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
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
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
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
15 matches
Mail list logo