Revert "Move _path_key_to_spec to ElementPathKey."

[tlento]

This reverts commit bcbf1bf.

The original layout of linkable_element, with the private helper
converting ElementPathKey to the relevant LinkableInstanceSpec,
was intentionally placed to avoid circular dependencies with
the WhereFilterSpec during predicate pushdown implementation.

The code configuration from the reverted commit is nicer in many
respects, but unfortunately an attempt to use it ran into
circular dependencies as expected, and the TYPE_CHECKING work-around
ultimately failed because of the way SerializableDataclass works.
Specifically, SerializableDataclass needs the class to create a concrete
object during its operation, so runtime access to the object is required
it's part of a SerializableDataclass hierarchy.

Since the SerializableDataclass mechanism is fully in use in the
implementation of some dbt cloud extensions we cannot easily
evalaute updates to that model here, and it is therefore much
simpler to just revert this change and move forward.

[tlento]

• Push resolved linkable elements through to WhereFilterSpec #1179
• Make linkable elements available in FilterSpecResolutionLookup #1178
• Revert "Move _path_key_to_spec to ElementPathKey." #1177 👈
• Make LinkabelElementSet non-optional in FilterSpecResolution #1176
• Add support for set type collections in the pretty-printer #1175
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tlento and the rest of your teammates on Graphite

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[plypaul]

👍

For context on the issue with SerializableDataclass - For deserialization, we need the classes at runtime because you need the class to create a concrete object. So doing if typing.TYPE_CHECKING won't work in those cases.

[tlento]

For context on the issue with SerializableDataclass - For deserialization, we need the classes at runtime because you need the class to create a concrete object. So doing if typing.TYPE_CHECKING won't work in those cases.

Yup, that is what I was seeing! I updated the PR description to include this information.