You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we have functions that can be embedded in predicates ("join", "lowercase", "date") and functions that can be used in computed fields (#40) ("conditional", "replace", "arithmetic") as well as the "link" function.
These should be consolidated, so they can be chained, but they should also be removed from MongoTripodTables, so they can be used elsewhere (and be more easily extended, tested, etc.), possibly/probably instantiated via a factory pattern.
The issue currently is how to reconcile the functionality between the two: predicate modifiers are working on the graph data, where the computed field functions expect tabular data (and they have different expectations on how they get that data and what's available at the point in time).
While we're at it, we should deprecate the 'predicate' modifiers being in a predicate property, since the whole semantics of that seem a little awkward.
The text was updated successfully, but these errors were encountered:
Currently, we have functions that can be embedded in predicates ("join", "lowercase", "date") and functions that can be used in computed fields (#40) ("conditional", "replace", "arithmetic") as well as the "link" function.
These should be consolidated, so they can be chained, but they should also be removed from MongoTripodTables, so they can be used elsewhere (and be more easily extended, tested, etc.), possibly/probably instantiated via a factory pattern.
The issue currently is how to reconcile the functionality between the two: predicate modifiers are working on the graph data, where the computed field functions expect tabular data (and they have different expectations on how they get that data and what's available at the point in time).
While we're at it, we should deprecate the 'predicate' modifiers being in a predicate property, since the whole semantics of that seem a little awkward.
The text was updated successfully, but these errors were encountered: