Closed angevineMiller closed 5 years ago
@angevineMiller Thanks for report. I think this is the same underlying issue as #787. The fact that __clsconf__
is a list would imply that MultiContainerInterface
s can support containing more than one type, and I agree that it would be useful to do so. Also, it is problematic that this looks like it works, only to fail after round trip. We'll look into this. @ajtritt, do you have any ideas? Would this fall under HDMF or pynwb?
This code, which is responsible for making the constructor, sits inside a loop over __clsconf__
:
https://github.com/NeurodataWithoutBorders/pynwb/blob/6bb2a01d9589d35ea5caf4b0620f862ca3e6162b/src/pynwb/core.py#L864-L868
It just needs to be moved out.
This hasn't been exposed yet since all the MultiContainerInterface classes in PyNWB define their own constructors.
I suspect if you look directly at the HDF5 file, then both Nodes and Edges exist. Is that not the case?
@tjd2002
For representing our behavioral data, we would like to create MultiContainerInterface extensions with multiple sub-containers (i.e. a Graph that contains many nodes and edges). In the example below, only one of the sub-containers is round-tripping its data contents. In particular, only the container which is listed first in the
__clsconf__
attribute of the MultiContainerInterface class definition.We only get the data for the nodes:
If, instead, I swap the order of the
__clsconf__
attribute to:Then, after round-tripping the data, we get the edges but not the nodes:
If, instead, I try to instantiate a Graph with nodes and edges directly, without using the adder methods,
It fails with:
Are we missing something important to be able to correctly define MultiContainerInterfaces with more than one sub-container?
Checklist