Right now #160 uses its own to_/from_storage methods to interact with the storage. Rather, let's inherit from Storage and use the _re/store functionality directly.
This depends on #161 so that including Storable in the MRO no longer causes such a costly import.
This should be quite straightforward for Node, but may be trickier for DataChannel, which requires a Node instance (the owning parent) at instantiation. This causes circular storage if we do it naively.
Related, for Macro we need to take care that children are already created at instantiation, so we may need to replace these with the loaded objects in the _restore. This would be computationally inefficient, but would allow people to modify macros and then save them.... (Probably macros need to get some internal flag for whether or not they've been tampered with, so that when it comes to logging them in a database we know about "true" instances of that macro vs "modified" instances......)
In any case, @pmrv and I discussed that it may be useful to modify the signature of to_object and restore. E.g. I am thinking it could also accept **kwargs that get passed to the class-specific _restore -- perhaps ChannelData._restore(storage, version, node), and in Node._restore we could do something like storage["inputs"][label].to_object(node=self) to pass the extra required info at re-store time without ever having in
Right now #160 uses its own
to_/from_storage
methods to interact with the storage. Rather, let's inherit fromStorage
and use the_re/store
functionality directly.This depends on #161 so that including
Storable
in the MRO no longer causes such a costly import.This should be quite straightforward for
Node
, but may be trickier forDataChannel
, which requires aNode
instance (the owning parent) at instantiation. This causes circular storage if we do it naively.Related, for
Macro
we need to take care that children are already created at instantiation, so we may need toreplace
these with the loaded objects in the_restore
. This would be computationally inefficient, but would allow people to modify macros and then save them.... (Probably macros need to get some internal flag for whether or not they've been tampered with, so that when it comes to logging them in a database we know about "true" instances of that macro vs "modified" instances......)In any case, @pmrv and I discussed that it may be useful to modify the signature of
to_object
andrestore
. E.g. I am thinking it could also accept**kwargs
that get passed to the class-specific_restore
-- perhapsChannelData._restore(storage, version, node)
, and inNode._restore
we could do something likestorage["inputs"][label].to_object(node=self)
to pass the extra required info at re-store time without ever having in