Calculation¶
- final class lsst.daf.relation.Calculation(tag: ColumnTag, expression: ColumnExpression)¶
Bases:
UnaryOperation
A relation operation that adds a new column from an expression involving existing columns.
Notes
Calculation
operations are assumed to be deterministically related to existing columns - in particular, aDeduplication
is assumed to have the same effect regardless of whether it is performed before or after aCalculation
. This means aCalculation
should not be used to generate random numbers or counters, though it does not prohibit additional information outside the relation being used. The expression that backs aCalculation
must depend on at least one existing column, however; it also cannot be used to add a constant-valued column to a relation.Attributes Summary
The columns the target relation must have in order for this operation to be applied to it (
Set
[ColumnTag
] ).Whether this operation depends on the number of rows in its target relation (
bool
).Whether this operation can change the number of rows in its target relation (
bool
).Whether this operation can remove all rows from its target relation (
bool
).Whether this operation depends on the order of the rows in its target relation (
bool
).Methods Summary
applied_columns
(target)Return the columns of the relation that results from applying this operation to the given target.
applied_max_rows
(target)Return the maximum number of rows of the relation that results from applying this operation to the given target.
applied_min_rows
(target)Return the minimum number of rows of the relation that results from applying this operation to the given target.
apply
(target, *[, preferred_engine, ...])Create a new relation that represents the action of this operation on an existing relation.
commute
(current)Describe whether and how this operation can be moved upstream of an existing one without changing the content of the resulting relation.
is_supported_by
(engine)Whether this operation is supported by the given engine (
bool
).simplify
(upstream)Return a simplified combination of this operation with another.
Attributes Documentation
- columns_required¶
- is_count_dependent¶
Whether this operation depends on the number of rows in its target relation (
bool
).
- is_count_invariant¶
- is_empty_invariant¶
- is_order_dependent¶
Whether this operation depends on the order of the rows in its target relation (
bool
).
Methods Documentation
- applied_columns(target: Relation) Set[ColumnTag] ¶
Return the columns of the relation that results from applying this operation to the given target.
- applied_max_rows(target: Relation) int | None ¶
Return the maximum number of rows of the relation that results from applying this operation to the given target.
- applied_min_rows(target: Relation) int ¶
Return the minimum number of rows of the relation that results from applying this operation to the given target.
- apply(target: Relation, *, preferred_engine: Engine | None = None, backtrack: bool = True, transfer: bool = False, require_preferred_engine: bool = False) Relation ¶
Create a new relation that represents the action of this operation on an existing relation.
- Parameters:
- target
Relation
Relation the operation will act on.
- preferred_engine
Engine
, optional Engine that the operation would ideally be performed in. If this is not equal to
target.engine
, thebacktrack
,transfer
, andrequire_preferred_engine
arguments control the behavior. Some operations may supply their own preferred engine default, such as the “fixed” operand’s own engine in aPartialJoin
.- backtrack
bool
, optional If
True
(default) and the current engine is not the preferred engine, attempt to insert this operation before a transfer upstream of the current relation, as long as this can be done without breaking up any locked relations or changing the resulting relation content.- transfer
bool
, optional If
True
(False
is default) and the current engine is not the preferred engine, insert a newTransfer
to the preferred engine before this operation. Ifbacktrack
is also true, the transfer is added only if the backtrack attempt fails.- require_preferred_engine
bool
, optional If
True
(False
is default) and the current engine is not the preferred engine, raiseEngineError
. Ifbacktrack
is also true, the exception is only raised if the backtrack attempt fails. Ignored iftransfer
is true.
- target
- Returns:
- new_relation
Relation
Relation that includes this operation. This may be
target
if the operation is a no-op, and it may not be aUnaryOperationRelation
holding this operation (or even a similar one) if the operation was inserted earlier in the tree via commutation relations or if simplification occurred.
- new_relation
- Raises:
- ColumnError
Raised if the operation could not be applied due to problems with the target relation’s columns.
- EngineError
Raised if the operation could not be applied due to problems with the target relation’s engine.
Notes
Adding operations to relation trees is a potentially complex process in order to give both the operation type and the engine to customize the opportunity to enforce their own invariants. This
final
method provides the bulk of the high-level implementation, and is called by theRelation
class’s convenience methods with essentially no additional logic. The overall sequence is as follows:apply
starts by delegating to_begin_apply
, which allows operation classes to replace the operation object itself, perform initial checks, and set the preferred engine.apply
then performs thepreferred_engine
logic indicated by thebacktrack
transfer
, andrequire_preferred_engine
options, delegating backtracking toEngine.backtrack_unary
.Engine.backtrack_unary
will typically call back tocommute
to determine how and whether to move the new operation upstream of existing ones.If backtracking is not used or is not fully successful,
apply
then delegates toEngine.append_unary
to add the operation to the root of the relation tree.The
Engine
methods are expected to delegate back to_finish_apply
when they have identified the location in the tree where the new operation should be inserted._finish_apply
is responsible for actually constructing theUnaryOperationRelation
when appropriate. The default implementation of_finish_apply
also callssimplify
to see if it is possible to merge the new operation with those immediately upstream of it or elide it entirely.
- commute(current: UnaryOperationRelation) UnaryCommutator ¶
Describe whether and how this operation can be moved upstream of an existing one without changing the content of the resulting relation.
- Parameters:
- current
UnaryOperationRelation
A unary operation relation that is the current logical target of
self
.
- current
- Returns:
- commutator
UnaryCommutator
A struct that either provides a version of
current.operation
that can be applied tocurrent.target
after a possibly-modified version ofself
, or an explanation of why this is impossible.
- commutator
Notes
The
commute
implementations for the provided concreteUnaryOperation
types assume that all unary operations preserve row order. If this is not the case in an engine, that engine should not implementEngine.backtrack_unary
or take this into account itself when determining whether operations commute.
- is_supported_by(engine: Engine) bool ¶
Whether this operation is supported by the given engine (
bool
).
- simplify(upstream: UnaryOperation) UnaryOperation | None ¶
Return a simplified combination of this operation with another.
- Parameters:
- upstream
UnaryOperation
Operation that acts immediately prior to
self
.
- upstream
- Returns:
- simplified
UnaryOperation
Operation that combines the action of
upstream
followed byself
, orNone
if no such combination is possible.
- simplified