2026/04/10

Friday, April 10, 2026 (#100)

Thursday Friday Saturday posts: prev < this > next

References 2026/04/09 (← links) 2026/04/11 (← links)

• 10:21 So now I'm thinking that maybe the Updater-class can be Command-dependent. I guess it depends -- for now, at least -- on whether the same EoS-detection method works for all main-command ops or just some. On the other hand, the Command class was specifically designed to support different options / operation-modes, so it makes a little more sense to have a mode-toggle there instead of in the Engine (or Server).
  • In any case, I've moved things around so the Engine Updater has access to the Server object (and hence the Engine object) instead of just the credentials-Command-line. This might or might not even make it possible to make its class Command-dependent; it seemed like it was a necessary step at the time, but then my focus fell apart.
  • I think maybe the idea was that if the Command is going to create the Updater instead of the Engine doing it, then something something something [???] PROFIT!!!
• 10:36 For one thing: if we want to have a different way of checking for EoS for each Updater, then it makes sense to move CheckForEnd() out of the Engine and into the Updater, which is what was calling it anyway.
  • CheckForEnd() needs access to the Session, but it can at least access that through the Engine (to which it now has access)... but is there a more direct way?
    • Yes: an Engine Updater object is initialized with FromEngineSession(), which does in fact take a Session object, which the parent-class makes available via OSession().
    • Maybe Updater::CheckForEnd() needs to be abstract at this level, though. Yes. Yes, it does. ...and now we need to create podlings to implement that differently, or maybe implement OnLoop() differently.
• 10:52 Oh, right! A key part of this was the idea that Session objects should come from the Command-object instead of the Engine, because the Engine was leaning towards needing some additional support-functions for each type of Command (or Sessions from each type), which suggests that they belong in the Command instead.
  • The example which made me think of this: Engine::OSession() calls Engine::NewSession() to create a Session if there isn't one yet, and that in turn either has to assume which Command we want to start it with (which is what it currently does) or else you have to pass a command to it -- which means passing it to OSession() every time just in case it hasn't been created, which is a mess. If the Command-object creates the Session, that simplifies things: the Engine can track which Command we're currently doing, and retrieve the Session from that -- and the Command will, of course, create a Session for itself if needed -- but then, of course, the Command needs access to the Engine's Starter in order to do that.
• 12:39 (one nap later) It thinks it is doing exports, but it seems to exit each export before any data is sent: all the SQL files are zero-length.
• 15:07 It looks like it's actually doing the first schema properly, but then something isn't resetting because the 882 bytes from that are still shown as being pulled from the process's stdout for every subsequent schema -- which is probably also why they're showing as EoS immediately.
• 15:25 The problem was that we need to open a new Session for each Schema, because otherwise we're running the old command.
  • Exports now working again.
  • Error-message reporting has apparently gone away again.
  • Unsurprisingly, the memory-leak is much larger now; I'm probably discarding stuff without properly closing/destructing it.
• 21:35 (one dinner and one space-capsule splashdown later) Exports look ok; import now gets stuck in that same loop. I should be able to diagnose it now, though, maybe?