2026/04/11

Saturday, April 11, 2026 (#101)

Friday Saturday Sunday posts: prev < this > next

References 2026/04/10 (← links) 2026/04/12 (← links)

• 09:16 It seems pretty clear the app's I/O streams aren't being set up right for the import process.
  • For one thing, both Listener and Lecturer are the same object ID.
  • I'm not sure why this is; different objects are being assigned to those roles.
    • ...although at first there was no object being set for the Listener.
• 09:36 It apparently does successfully get the schema listing, but then gets stuck after creating or replacing the one it is importing.
  • The problem, therefore, is presumably that stuff isn't getting properly reset to run a second SQL command (CREATE OR REPLACE) after running the first one.
  • ...but also, why are the streams the same.
• 10:06 Renamed the access-methods for clarity, and... now the IDs are different, as they should be? (Or was I just misreading them?)
  • They are, of course, still not being reset after the first command.
  • Q. Why is CanalSetup() being run twice for each command?
    • A. Because it's called at the top of DoInOutLoop(), and also from DoCommand() which also calls DoInOutLoop().
      • Fixed by removing extra call from DoCommand() in both Proc and SSH2.
  • Q. Why is the App Lecturer not getting/staying set?
    • A. Because we're just sending a short command, so we're sending it directly rather than buffering it.
      • (...and that's also why the code doesn't show a message when it's missing: because sometimes it is, and that's ok.)
• 11:45 I think the streams are all being reset properly, but still stuck in a loop...
  • Q. What tells the loop when to exit?
    • A. Either of two things:
      • (1) Session::IsRunning(), which in this case is defined in Proc, where it is pretty reliable: if this goes FALSE, the loop exits.
      • (2) $doBreak, which is what NewSchemaList() uses.
      • We want to keep the process running, so clearly we need set $doBreak = TRUE which means we need a way to detect when the CREATE OR REPLACE and USE commands have exited. Will the same method work?
        • Apparently not, since the same detection-method is getting called. I guess I need to look at what we're receiving.
• 14:58 (one Costco Pharma trip, three slices of leftover pizza, and one dead un-jugged rabbit fish later...) I think what needs to happen is that the end-of-data detector needs to be configurable as to what it looks for, so that when we have a "silent" command (like CREATE OR REPLACE) we can immediately follow that up with a SELECT "<some arbitrary string>" which we can then look for.
  • The problem, once again, is likely to be getting the config data from {where the command is specified} over to the Updater. This is threatening to make my head start hurting again.
• 18:10 (one shower and two brain-resetting-but-time-wasting activities later) The obvious-ish way to deal with this is to have the Syntax class return Command objects instead of strings, so we can include an appropriate EoS-detection term, but... is this making things more complex than necessary?
  • The Syntax class would need to know which Command-class to use -- but it can get that from the Engine Client, to which it does have access via the Engine by which it is constructed, so that's not a dealbreaker. I'm just not sure there isn't a better way... like, setting the attributes when the command is initiated... but again, there might be Engine-dependent quirks which that could not resolve, and this could handle those, I think? ...or at least it would have a better whack at handling them properly.
  • I think there might be a class-structure conflict, though. If we want to be able to set the Command string arbitrarily, then we have to descend from Settable -- but the Command-family which is constructed with an Engine does not descend from that.
• 18:48 ...now, please remind me, past!me: where is the Updater created? I need to know how I would get config information from the Command into the Updater, if this is going to work...
  • ...oh, right, it's created by the Command. How frightfully convenient!
• 18:52 Maybe the Syntax class should just be a collection of Command-class definitions... except I don't want to have to define each of them for each Engine-type (at most, some commands might need tweaks to work properly, but normally the same SQL should work across all SQL-oriented Engines)...
  • Okay, here's the thing: the Command clade-family that is divided up by Engine-type is the CLI syntax used to start a Session. The set of Command-clades we need now is for running within a Session -- so they don't need to be part of the same clade-family; they can be a parallel branch.
• 21:24 This is either a pretty elegant solution or else a total clusterfuck; I don't see a lot of daylight between those two options.