Phlex handle interface

[knoepfel]

Users will have programmatic access to data-product provenance through a Phlex handle. The behaviors of and information available through a handle need to be discussed.

[knoepfel]

Behaviors

I argue that:

1. A data-product handle must provide access to one and only one data product.
2. A constructed handle object is always valid—i.e. access to the data product is guaranteed upon successful construction.
3. Handles should not be default-constructible (consequence of 2)
4. It is always safe to dereference a handle.
5. It is an error if a handle cannot be constructed when access to a data product is requested.
   • A suitable consequence could be an exception throw.

[knoepfel]

See:

• Handles are valid upon construction #96

[knoepfel]

Data accessible through a handle

I argue that the following should be accessible through a data-product handle:

1. the data product itself
2. the index of the data cell to which the data product belongs
   • This is not a single number; it would be a tuple of identifiers like: (run: 4, subrun: 8, spill: 15)
3. the data-product concept modeled by the concrete data-product type
4. the creator name, which includes:
   1. the algorithm name
   2. the name of the module in which the algorithm was registered
5. the product suffix
   • A user is not always required to provide a product suffix—the product suffix is used to disambiguate between multiple products of the same type returned by the same algorithm invocation.
   • This term replaces the term product name, although the latter will be explored further.
6. the phase name (or stage name)

[knoepfel]

After discussion with @marcpaterno, we both agree that product name is a weak term. Actually, a Latin term that represents the concept well is praenomen (see https://en.wikipedia.org/wiki/Roman_naming_conventions):

The most important of these names was the nomen gentilicium, or simply nomen, a hereditary surname that identified a person as a member of a distinct gens. This was preceded by the praenomen, or "forename", a personal name that served to distinguish between the different members of a family.

[knoepfel]

Based on various discussions, product name will be replaced with product suffix for now. A more thorough evaluation of these concepts will become part of the F2 milestone.

[knoepfel]

See:

• Information accessible through phlex::handle<T> #265

[knoepfel]

See:

• Access stage name through phlex::handle<T> #451

[pcanal]

A data-product handle must provide access to one and only one data product.

Related question. How should the user model cases where there could be data or there could not be data and they need to know whether it is there or not (for example the data product is 'trigger magnitude' where zero is a valid value and 'did not trigger' is another)?

[pcanal]

A good answer is that in this case, the user should make the conditionality explicit and use something like std::optional.

[knoepfel]

Agreed. Currently in Phlex, the conditional execution of code should be represented by specifying a filter clause—the algorithm will not be executed unless such data products are available. If we want to support the execution of algorithms for data products that may or may not be there, the input-parameter type to the algorithm would need to be a nullable type (e.g., std::optional<T const> or T const*). We can consider accommodating that need should it become a requirement.

[barnaliy]

Something like this?

// Exceptional failure: Requesting data that should exist but doesn't
// Use when product is required by algorithm logic - absence is a framework error
// Example: final analysis step that depends on upstream reconstruction
auto h = get_handle("track_finder", "primary");
// throws if track_finder didn't produce tracks for this event

---

// Expected absence: Querying data that may not exist as part of normal processing flow
// Use when checking for optional products - absence is expected and handled
// Example: scanning events for rare signatures where reconstruction may not have run
auto opt_h = find_handle("trigger_algo", "hardware");
if (opt_h) {
// Trigger data exists for this spill, process it
auto& trigger = *opt_h;
} else {
// No trigger this spill, skip or use alternative logic
}

[knoepfel]

@barnaliy, that's the right idea, but we don't want users to explicitly invoke anything that creates a handle. The framework creates any handles that the user may need.