albertogpz commented on pull request #6028:
URL: https://github.com/apache/geode/pull/6028#issuecomment-789988265
> > > > Usually the queries that don't have indexes are considered "correct"
and the ones with indexes usually were checked against those results.
> > > > Was the issue due to the map index not mapping values it didn't know
about?
> > > > A solution down the line might be to allow custom indexing.
> > > > Is there a way to disable the != only for queries that use the map
index? Queries that use the base compact range index should still be able to
execute != in a timely fashion.
> > >
> > >
> > > I created the test in order to compare queries with and without
indexes. Nevertheless, I think that currently queries without indexes do not
give the right results with where clauses in which the map for the key passed
is compared with null, for example: "positions['SUN'] != null" or
"positions['SUN'] = null. In these cases for entries that contain the map
(positions != null) but positions does not contain the "SUN" key, it considers
that positions['SUN'] is null.
> > > I have changed the code in the latest commits to work the way I
expected.
> > > Besides, I have added a change so that indexes are used again when
using CompactRangeIndexes but not when using CompactMapRangeIndexes.
> > > There's only 3 test cases that are failing and I still need to
investigate.
> >
> >
> > The cases that are failing try to create the following index:
> > pf.collectionHolderMap[(pf.ID).toString()].arr[pf.ID]
> > They also fail if the index is:
pf.collectionHolderMap[(pf.ID).toString()]
> > I wonder what type of index is that. According to the documentation,
when you create a Map index you specify either "*" in order to create an index
for every key or one or more keys (v.g. "SUN", IBM",...) but in those cases the
index contains something variable.
> > Does it make sense to support it given that there is no such thing in
the documentation?
>
> pf.collectionHolderMap[(pf.ID).toString()] <= I think(not 100% sure) this
can be considered equivalent to entry.mapField["ID value as key"] So similar to
a map index
>
> pf.collectionHolderMap[(pf.ID).toString()].arr[pf.ID] <= I think is a map
index where the value that is mapped happens to be an array. For example
"SELECT * FROM /exampleRegion p WHERE p.collectionHolderMap.get('1').arr[0] =
'0'"
>
> This query is listed in the doc here:
https://gemfire.docs.pivotal.io/96/geode/getting_started/querying_quick_reference.html
> Although it probably discussed in detail in the indexing portion. I would
guess the docs got too cluttered with all the types of queries that are
possible with OQL (as one can continue to drill down into objects infinitely)
The query makes perfect sense to me. What is not that clear is that you use
a variable as a key in the map index. Because in that, case,
> > > > Usually the queries that don't have indexes are considered "correct"
and the ones with indexes usually were checked against those results.
> > > > Was the issue due to the map index not mapping values it didn't know
about?
> > > > A solution down the line might be to allow custom indexing.
> > > > Is there a way to disable the != only for queries that use the map
index? Queries that use the base compact range index should still be able to
execute != in a timely fashion.
> > >
> > >
> > > I created the test in order to compare queries with and without
indexes. Nevertheless, I think that currently queries without indexes do not
give the right results with where clauses in which the map for the key passed
is compared with null, for example: "positions['SUN'] != null" or
"positions['SUN'] = null. In these cases for entries that contain the map
(positions != null) but positions does not contain the "SUN" key, it considers
that positions['SUN'] is null.
> > > I have changed the code in the latest commits to work the way I
expected.
> > > Besides, I have added a change so that indexes are used again when
using CompactRangeIndexes but not when using CompactMapRangeIndexes.
> > > There's only 3 test cases that are failing and I still need to
investigate.
> >
> >
> > The cases that are failing try to create the following index:
> > pf.collectionHolderMap[(pf.ID).toString()].arr[pf.ID]
> > They also fail if the index is:
pf.collectionHolderMap[(pf.ID).toString()]
> > I wonder what type of index is that. According to the documentation,
when you create a Map index you specify either "*" in order to create an index
for every key or one or more keys (v.g. "SUN", IBM",...) but in those cases the
index contains something variable.
> > Does it make sense to support it given that there is no such thing in
the documentation?
>
> pf.collectionHolderMap[(pf.ID).toString()] <= I think(not 100% sure) this
can be considered equivalent to entry.mapField["ID value as key"] So similar to
a map index
>
> pf.collectionHolderMap[(pf.ID).toString()].arr[pf.ID] <= I think is a map
index where the value that is mapped happens to be an array. For example
"SELECT * FROM /exampleRegion p WHERE p.collectionHolderMap.get('1').arr[0] =
'0'"
>
> This query is listed in the doc here:
https://gemfire.docs.pivotal.io/96/geode/getting_started/querying_quick_reference.html
> Although it probably discussed in detail in the indexing portion. I would
guess the docs got too cluttered with all the types of queries that are
possible with OQL (as one can continue to drill down into objects infinitely)
The query makes perfect sense to me. What is not that clear is what type of
index is created because neither a fixed value nor "*" is used as a key to the
map but rather a variable. That leads me to think that it is not a Map index.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
