SG-39225 Support specific keys for entity optimization

[carlos-villavicencio-adsk]

This pull request refactors the _get_type_and_id_from_value function to improve how entity dictionaries are processed. The function now extracts a broader set of allowed keys, not just type and id, making the output more informative and flexible.

[julien-lang]

Could you add a test case showing the exact problem that we are trying to fix here, please?

I recently worked with local storage path (relative path and all) and I don't understand the problem (nor I experience it with my own tests).

[julien-lang]

THanks for the update. One more minor comment.

Also, can you update the test case please to include a local storage update example?

[julien-lang]

Sorry, I have a few more comments

[julien-lang]

Should we add and "id" in field_value and "type" in field_valuehere too?

[julien-lang]

Or call recursivity:

def _optimize_filter_field(field_value: Union[dict, list], recursive: bool =True) -> Union[dict, list]:
    """
    For an FPT entity, returns a new dictionary with only the type,
    id, and other allowed keys.
    If case of any processing error, the original dictionary is returned.

    At least `type` and `id` keys are required to do the optimization
    """
    allowed_keys = {
        "id",
        "type",
        "url",
        "name",
        "content_type",
        "local_path",
        "storage",
        "relative_path",
    }
    try:
        if (
            isinstance(field_value, dict)
            and "id" in field_value
            and "type" in field_value
        ):
            return {key: field_value[key] for key in allowed_keys if key in field_value}

        elif recursive and isinstance(field_value, list):
            return [_optimize_filter_field(fv, recursive=False) for fv in field_value]

    except (KeyError, TypeError):
        LOG.debug(f"Could not optimize entity value {field_value}")

    return field_value

[carlos-villavicencio-adsk]

I;ve added id and type for now. But I'll take a look the implications about using recursion here.

[julien-lang]

Thanks!

Also, one more crazy idea: can we get rid of try/except (KeyError, TypeError)? I mean at this point in the code, which exception can we expect?

[carlos-villavicencio-adsk]

Great suggestion. Making it recursive slightly improved performance by a few hundredths of a second.

I took this chance to add more and more tests cases to validate more scenarios.