pyiron / pyiron_workflow

Graph-and-node based workflows
BSD 3-Clause "New" or "Revised" License
11 stars 1 forks source link

Storage: Use `tinybase.storage.Storable` directly #162

Closed liamhuber closed 7 months ago

liamhuber commented 8 months ago

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

liamhuber commented 7 months ago

My current thinking is to instead modify the infrastructure to use __get(set)state__ instead.