Dimension links

[achilleas-k]

Implements DimensionLink as discussed in G-Node/nix#824 (closes #466).

Some notes and points for discussion:

• The name of the link in the backend (inside the HDF5 file) is simply link. Therefore, a dimension with a linked object has the following path:
  /data/<block name>/data_arrays/<array name>/dimensions/<dim number>/link/<linked object id>
• The dimension link object holds an attribute that specifies the type of the object it's linking. The value of the attribute is either "DataArray" or "DataFrame".
• The dimension module has no access to the DataFrame and DataArray classes so it can't return or initialise an object of those types. We could do it for the DataFrame, but importing DataArray would result in an import cycle. DataArrays need to be able to create Dimensions, so Dimensions can't create (initialise) DataArrays.
• Do we want to allow setting values or attributes through the dimension link to the underlying data object? For instance, should the ticks or label of a RangeDimension that links to a DataArray be modifiable through the RangeDimension object?
  • I haven't added support for this, but depending on the answer, I'll have to either add support for it or raise an exception.
• We don't allow dimensions that link to a DataFrame to have a None index, for linking to the entire DataFrame. We initially supported this in the DataFrameDimension implementation, but now this ability or an analogous one isn't supported. I think we agreed on this in our discussion, but I wanted to make sure I'm remembering correctly.
• Users are allowed to link a DataArray to a dimension with an index that is out of bounds for the array, as long as the dimensionality is correct. My thinking here was that the underlying (linked) DataArray can be resized to fit or break the indexing, so the error will be caught on data retrieval or validation. The dimensionality of a DA can't change, so we check for this during linking.

[lgtm-com]

This pull request introduces 1 alert when merging f1aeb40 into 2e6491f - view on LGTM.com

new alerts:

• 1 for Unused import

[lgtm-com]

This pull request introduces 1 alert when merging 7677c6e into 2e6491f - view on LGTM.com

new alerts:

• 1 for Unused import

[jgrewe]

this looks very nice to me!
one point:

• we do have the same need for such linking on the feature and I wonder, whether some of the DimensionLink class functionality should go into a common superclass for DimensionLinks and Feature Links, the first needs the index, the latter the link_type (tagged, untagged, indexed)

did not think about it but do we need the invalidUnit import in DataArray?

[achilleas-k]

this looks very nice to me!
one point:

• we do have the same need for such linking on the feature and I wonder, whether some of the DimensionLink class functionality should go into a common superclass for DimensionLinks and Feature Links, the first needs the index, the latter the link_type (tagged, untagged, indexed)

Good idea. Some low level functionality could go there, like all the underlying attribute access methods. It might also fix the import cycle issue and let us instantiate the data object through the dimension link, but I'll have to think about it more and then try it.

I'd like to do this in a followup PR though.

did not think about it but do we need the invalidUnit import in DataArray?

We used to need it for the AliasRangeDimension, since having a non SI unit in a dimension wasn't supported at some point. I think we allow it now, just not scaling.

Anyway, cleaned out all Unused vars and imports now.

[lgtm-com]

This pull request introduces 1 alert when merging 8d84599 into 2e6491f - view on LGTM.com

new alerts:

• 1 for Suspicious unused loop iteration variable