Semantic conversions between objects and specs leads to circular import dependencies about metricflow HOT 3 CLOSED

In the short term, the plan here is to insert a protocol for DataSourceSemantics along with a separate "converter" class to do the WhereClauseConstraint -> SpecWhereClauseConstraint. The converter class will depend on the protocol, DataSourceSemantics will implement it, and we'll rely on the duck-typing to give us both type checking and a lack of direct import dependencies from semantic containers into the spec converter.

I might also play a similar trick in order to eliminate the existing model object -> spec import dependency for semi additive constraints, adding a "spec" version of that constraint and loading that in as appropriate.

from metricflow.

@plypaul @WilliamDee does this make sense to you all? I'll send you a message, and in the meantime I'll be trying this out to see if it works as I hope it will.

from metricflow.

I think #225 gets us close enough on this for the time being. Until we can think about how to restructure our semantic containers the following two rules will suffice:

1. Restructure or refactor as needed to resolve and prevent circular dependencies instead of hacking around the issue
2. Avoid adding import dependencies between specs and model objects, and never have specs and model objects depend on semantic containers

from metricflow.