awslabs/amazon-documentdb-tools

bug in checking COMPOUND_INDEX_MAX_KEYS?

codekiln opened this issue · 0 comments

It seems like the check for DocumentDbLimits.COMPOUND_INDEX_MAX_KEYS currently happens by counting keys in the index dict, not in the index['key'] dict:

https://github.com/awslabs/amazon-documentdb-tools/blob/master/index-tool/migrationtools/documentdb_index_tool.py#L404:

                    # Check for indexes with too many keys
                    if len(index) > DocumentDbLimits.COMPOUND_INDEX_MAX_KEYS:
                        message = 'Index contains more than {} keys'.format(
                            DocumentDbLimits.COMPOUND_INDEX_MAX_KEYS)
                        compatibility_issues[db_name][collection_name][
                            index_name][self.EXCEEDED_LIMITS][message] = len(
                                index)

Instead, it seems to me like it should be farther down, when testing index['key']:
https://github.com/awslabs/amazon-documentdb-tools/blob/master/index-tool/migrationtools/documentdb_index_tool.py#L436-L437

# Check for unsupported index types like text
if key_name == self.INDEX_KEY:
    for index_key_name in index[key_name]:
        key_value = index[key_name][index_key_name]
        if (
            key_value
            in DocumentDbUnsupportedFeatures.UNSUPPORTED_INDEX_TYPES
        ):
            compatibility_issues[db_name][collection_name][
                index_name
            ][self.UNSUPPORTED_INDEX_TYPES_KEY] = key_value

I looked in the tests and didn't think I saw any tests for DocumentDbLimits.INDEX_KEY_MAX_LENGTH;
tmc.metadata.json doesn't contain any index with more than COMPOUND_INDEX_MAX_KEYS=32 keys.

While this bug may not bite many people, it made me doubt that I understood the expected structure passed as metadata to def find_compatibility_issues(metadata).