quantity.physobj¶

Override to add the quantity field.

Fields

quantity = <anyblok.column.Decimal object>¶

Quantity

Depending on the PhysObj Type, this represents in reality some physical measure (length of wire, weight of wheat) for PhysObj stored and handled in bulk, or a number of identical items, if goods are kept as individual pieces.

There is no corresponding idea of a unit of measure for bulk PhysObj, as we believe it to be enough to represent it in the PhysObj Type already (which would be, e.g, respectively a meter of wire, a ton of wheat). Note that bulk PhysObj can be the result of some Unpack, with the packaged version being itself handled as an individual piece (imagine spindles of 100m for the wire example) and further packable (pallets, containers…)

This field has been defined as Decimal to cover a broad scope of applications. However, for performance reasons, applications are free to overload this column with other numeric types (i.e., supporting transparently all the usual operations with the same syntax, both in Python and SQL).

Examples :

• applications not caring about fractional quantities might want to overload this column with an Integer column for extra performance (if that really makes a difference).
• applications having to deal with fractional quantities not well behaved in decimal notation (e.g., thirds of cherry pies) may want to switch to a rational number type, such as mpq type on the PostgreSQL side), although it’s probably a better idea if there’s an obvious common denominator to just use integers (following on the example, simply have PhysObj Types representing those thirds of pies alongside those representing the whole pies, and represent the first cutting of a slice as an Unpack)

Override to have behavorial tests for Split/Aggregate.

As a special case, the behaviours specify whether Split and Aggregate Operations are physical (represent something happening in reality), and if that’s the case if they are reversible, using {"reversible": true}, defaulting to false, in the split and aggregate behaviours, respectively.

We don’t want to impose reversibility to be equal for both directions, as we don’t feel confident it would be true in all use cases (it is indeed in the ones presented below).

Reality of Split and Aggregate and their reversibilitues can be queried using are_split_aggregate_physical(), is_split_reversible() and is_aggregate_reversible()

Use cases:

• if the represented goods come as individual pieces in reality, then all quantities are integers, and there’s no difference in reality between N>1 records of a given PhysObj Type with quantity=1 having identical properties and locations on one hand, and a record with quantity=N at the same location with the same properties, on the other hand.
• if the represented goods are meters of wiring, then Splits are physical, they mean cutting the wires, but Aggregates probably can’t happen in reality, and therefore Splits are irreversible.
• if the represented goods are kilograms of sand, kept in bulk, then Splits mean in reality shoveling some out of, while Aggregates mean shoveling some in (associated with Move operations, obviously). Both operations are certainly reversible in reality.

Methods

are_split_aggregate_physical = <function Type.are_split_aggregate_physical>[source]¶

is_split_reversible = <function Type.is_split_reversible>[source]¶

is_aggregate_reversible = <function Type.is_aggregate_reversible>[source]¶