2026/10/17

Saturday, October 17, 2026 (#290)

prev ⇐ Friday Saturday Sunday ⇒ next

References 2026/10/16 (← links) 2026/10/29 (← links)

Main Work

Still working on DBA, which is now dumping each schema using the previous schema's filename.

The core of the problem (or closer to it) seems to be assignment of responsibility between Sys\FileSys\Node\inout\Fil, Sys\FileSys\Node\venue\VenNode, and (to a lesser extent, I think) Sys\InOut\Connx\Stream\Rsrc.

• VenNode is the abstract Venue clade, so does nothing low-level -- except that it has subclades, Local and SFTP, for handling details that change depending on where the file is.
  • Tentatively, all these subclades add to the mix is to choose which VenSpec and VenDir clades to use for those operations. Neither of those are involved in Stream-management, so as far as dealing with this bug, we can (hopefully) just think of VenNode as a single class.
• Fil handles operations on nodes that are specifically files rather than directories.
  • This clade does deal with Stream objects, providing methods for Opening in particular access-modes, read/write/seek, and information.
  • Its ActualOpen() and ActualShut() methods pass the buck back to VenNode, however, which currently passes the buck again to the Stream object. This will only work if the Stream object knows how to open itself.
  • In the particular case I'm looking at (trying to open "information_schema.sql.json" for writing), Stream->ActualOpen() again either tries to re-kick the can through a Door -- a mechanism put into place for when it doesn't make sense for the Stream to open itself (i.e. process-streams) or expects the resource already to be set.
    • So, Q1: where is the code which can actually open a local file, and who should be calling it?

A1

VenNode->NewRStrm() calls fopen($this->SSpec_forOpen), which opens a stream in either local or SFTP contexts. This seems a little klugey, but as long as we don't have any venues in which it does not work, it also seems like the right way to do it.

...and that is called when VenNode->RStrm is read before it has been set.

So: VenNode->ActualOpen() should be accessing $this->RStrm.

15:25

I've fixed the resource-creation issue, but now we're back to the export looping forever without saving any bytes (thought it does at least write the .json meta-file).

16:40

I wonder if there's any good way to embed some kind of "contract" between Stream-objects and the I/O processes... like, the object will have an indicator that says it is supposed to be used in a certain way, and the code running the I/O loop will check for those indicators in each of the Streams it reads/writes. ...and this should also allow for a way to check that a duplicate Stream of the same use-intent doesn't get created.

20:35

It's not a bad idea, in principle, but after thinking about it a bit I get the impression that implementing it without causing even more tangles would be difficult.

There has got to be a way to make this situation more debuggable, though. ...and part of the problem is still not yet actually knowing what's causing the actual problem.