You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@geode.apache.org by GitBox <gi...@apache.org> on 2021/03/03 20:05:29 UTC

[GitHub] [geode] albertogpz edited a comment on pull request #6028: WIP, DO NOT REVIEW. Do not create index when indexKey is null

albertogpz edited a comment 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 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.
   I have made a last change (see last commit) that treats these indexes as regular indexes, not Map indexes, and all test cases seem to pass.


----------------------------------------------------------------
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:
users@infra.apache.org