Revert "Reimplementation of DataHandle (!462)"

This reverts merge request !462 (merged)

I need to create this reverted MR so that I can test other features of v30r4 in isolation.

Doesn't need to be merged.

• [2018-11-03 00:04] Validation started with lhcb-lcg-dev3#700
• [2018-11-03 00:05] Validation started with lhcb-lcg-dev4#704
• [2018-11-03 00:08] Validation started with lhcb-dd4hep#47
• [2018-11-03 00:09] Validation started with lhcb-tdr-test#347
• [2018-11-03 00:11] Validation started with lhcb-gaudi-head#2049
• [2018-11-03 00:19] Validation started with lhcb-sanitizers#53
• [2018-11-03 08:06] Validation started with lhcb-gaudi-merge#628
• [2018-11-04 00:05] Validation started with lhcb-dd4hep#48
• [2018-11-04 00:05] Validation started with lhcb-lcg-dev4#705
• [2018-11-04 00:07] Validation started with lhcb-tdr-test#348
• [2018-11-04 00:08] Validation started with lhcb-gaudi-head#2050
• [2018-11-04 00:08] Validation started with lhcb-lcg-dev3#701
• [2018-11-04 00:09] Validation started with lhcb-sanitizers#54
• [2018-11-04 08:43] Validation started with lhcb-tdr-test#349
• [2018-11-05 00:10] Validation started with lhcb-dd4hep#49
• [2018-11-05 00:10] Validation started with lhcb-lcg-dev3#702
• [2018-11-05 00:12] Validation started with lhcb-lcg-dev4#706
• [2018-11-05 00:12] Validation started with lhcb-gaudi-head#2051
• [2018-11-05 00:15] Validation started with lhcb-sanitizers#55
• [2018-11-05 00:18] Validation started with lhcb-tdr-test#350

mentioned in merge request lhcb/Rec!1272 (merged)

@hgraslan, I think a backward compatibility hack would be more useful.

I didn't realize !462 (merged) was not backward compatible, I'm sorry.

@clemenci The original DataHandle abstraction was so thoroughly leaky that a full backwards compatibility hack would need to emulate not just the interface, but also the full implementation... including its undesirable properties.

This is why I asked @leggett to be more specific about use cases a while ago. It seems like we will be able to have that discussion next week.

In the worst case, I can build an incomplete DataHandle v1 facade that bombs at runtime when an unsupported operation is invoked. But I hope we can all agree that this is a last-resort solution.

I've been trying to implement Athena code with dataDependencies() instead of input/outputHandles(), and while it's good for most use cases, it is unfortunately not sufficient for all of them, where the IDataHandleHolder has to access something in the DataHandle interface that's not in the DataObjID. For example, a parent algorithm needs to call start on the CondHandles that it owns (or inherits via AlgTools). Note that also DataHandle::isCondition() is not in the v2 interface, though this can be surmounted with some ugly string grepping.

@leggett Thanks for looking this up! Please keep enumerating such families of use cases where data dependencies alone seem insufficient, so that we can more easily discuss them in the next two days and afterwards.

What would be also extremely useful is to know in which context these APIs are used, as that can affect the solution to the problem greatly. To give an example, if isCondition() were used to enumerate condition dependencies, then that could be expressed in terms of data dependencies by extending the dataDependencies(mode) API into a dataDependencies(mode, lifetime) one, where "lifetime" has a default value that selects all data lifetimes but allows optionally selecting event data or conditions in particular. A long time ago, this MR used to go in this direction, before taking a more conservative route.

mentioned in merge request !798 (closed)

approved this merge request

assigned to @clemenci

changed milestone to %v30r5

merged

mentioned in commit d7b4ebe0