2026/03/01

Sunday, March 1, 2026 (#60)

Saturday Sunday Monday posts: prev < this > next

Coding Convention Note

I think I've worked out that instead of having just a few general-purpose ItWent podlings, it's better to have one for each operation-type. The exact nature of each can then be custom-tweaked for that purpose.

Also, I'm using the prefix "Op" for all these clades (especially in local aliases), so they sort out together.

11:38

So: when I do a local export, some of the schemas are returning an error (code 2) but still producing .sql files (no data, but the usual comment-headers). I thought at first maybe this was just because they're system schemas which can't be fully exported, but one of them is a schema I imported last night (and which has no apparent problems, from what I can tell, aside from this).

The code 2 comes from proc_get_status(), but it's presumably defined by the process and not proc_open() itself (so I can't look there to see what it means). The process is mysqldump, but the documentation on that doesn't mention any error-codes. Maybe I need to make sure I'm capturing any error-stream output when I run proc_open().

14:37

Reminder to self of the difference:

• A Pool is a collection of Streams.
• A Canals is a collection of Canals, aka Conductors, aka Stream pairs (input and output).

...and no, I am not loving the terminology here. I'm kinda hoping there's some way to get rid of Pool, which is only used for Proc. What happens now is that Proc creates a Pool object via OAPipes() (older terminology), and then populates it with the array from proc_open() via Pool->SetVals(). What if we could somehow create the Canals object instead?

Although it may lead to a better solution, the fact that the elements of the array passed to proc_open() could be native-stream resource variables instead of descriptor arrays.

• The descriptor-array also allows specifying a filespec instead of requesting a native stream, but I can't see any easy way to intercept the data being transmitted in that case, so this is not very useful.
• For that matter, I can't quickly think of any way to intercept data being transmitted via a native stream, either, without getting into stream-wrappers or something. That's quite possibly the "right" way to do this kind of thing, but at least for now it feels very black-box / tall, steep learning-curve.

15:24 Code Changes

Just to help de-clutter things and thereby reduce cognitive load, I'm going to:

• [DONE] rename …Runner\Local\aux\ProcStatus to …Runner\Local\aux\Proc\Status
• [DONE] move [WFe]IO\Aspect\Connx\aux\A\Pool\Pipes to …Runner\Local\aux\Proc\Pipes

Local exports are still working after this. Remote is broken.

• Had to re-parent [WFe]IO\Aspect\Connx\Runner\ops\OpCmd from [WFe\IO\Aspect\Connx\aux\itWent\ProcOp to [WFe]Sys\Events\ItWent. I may (will) need to modify further depending on what features are missing/needed.

Remote exports now working again. Local exports broken, of course, because [WFe]Sys\Events\ItWent does not have FromOAPipes(). I think what happens next is that I...

• [DONE] create an ItWent podling that does have FromOAPipes(), and then override OOpCmdNew() in Proc.

Local and remote exports working(ish) again... bearing in mind that:

• remote DoCommand() still needs reorganizing to match what I've done with Local (Proc), and I'm not sure how complete that was either.
• some schemas are still erroring on local export -- I need to include checking of the process's Lecturer streams (stdout & stderr).

21:25

Well that worked:

Error Message: mysqldump: Got error: 1044: "Access denied for user 'root'@'localhost' to database 'information_schema'" when using LOCK TABLES

Now I just need to tidy things up -- and also feed that information to the Messages classes (which used to happen, but I guess it got uncoupled at some point). TODO

...and indeed we now do have details regarding the mysterious error on the imported schema:

Error Message: mysqldump: Got error: 1449: "The user specified as a definer ('root'@'gonzo.local') does not exist" when using LOCK TABLES

I'm not sure of the best way to fix this, but it is certainly fixable.

22:31 How-It-Works Notes

• The Engine endpoint Client (or, apparently, a subsidiary such as EngDbExport) object calls the Client's MsgsOp(), which returns an Engine-specfic [WFe]Sys\Events\MsgsOp object (e.g. [WFe]Sys\Data\Engine\aux\msgs\Maria\cOps or [WFe]Sys\Data\Engine\aux\msgs\MySQL\cOps).
  • The MsgsOp class to use is defined by the Client class's MsgsOpClass() function.
• The MsgsOp object then provides ErrorsAdminClass(), allowing [WFe]Sys\Events\caMsgsOp to use the right [WFe]Sys\Events\Message\Errors class (e.g. [WFe]Sys\Data\Engine\aux\msgs\MySQL\caErrors) to look up the error from its message-text by calling caErrors::FromMessage(<message text>).

Pieces of this seem unnecessarily complex, but it may just be excessively granular separation-of-concerns.

[overnight thought] However, none of it is actually being invoked at present (as far as I can tell), so I'll probably end up rethinking how that happens.