|
Tuesday, March 10, 2026 (#69)
|
|
09:07
I think what I need to do is look at the sequence of calls that do an Export, make note of which bits of functionality are taking place at each step, and then try to map that onto the Import process.
how the Export process works
- starts with
Engine/aux/ActionRq/Admin/ExportDtbase::Go()
- The DBA-podling is not involved. Maybe it should handle user-output?
Go() then does these things:
- fetch & configure the filespec-template object
- get list of Schema objects
- for each Schema object (
$oSchema):
- get filespec from template object
- create a file-node object (
$ofData) from that filespec
- call
$oSchema->DoExport($ofData)
$oSchema->DoExport($ofData) does these things:
- informs the user of what is happening ("Exporting <schema name> to <filespec>:")
- sets up the MetaPair (data-file / info-file) object
- configures the data-file & info-file (maybe MetaPair should handle this?)
- saves the start-time to the info-file
- creates a file-stream object (
$oDestStream) from the data-file-node object
- calls
$this->ExportToStream($oDestStream)
$oSchema->ExportToStream() does these things:
- opens the Schema (via Connx trait)
- creates an Updater object
- provisions
$oDestStream with the Updater object
- creates a blank Command object (
$oCmd)
- sets
$oDestStream as $oCmd's Listener
- provisions
$oCmd with the schema-name (which is all that is needed in order for the end-server to formulate the dump command)
- creates a Buffer object to receive errors, and sets it as
$oCmd's ErrorBin
- get the next-link Server object (
$oServer) and call $oServer->DoCommand($oCmd)
I'm leaving out post-command tidy-up (closing things, error-handling) for now.
20:06
Another part of non-parallelism which I think is throwing me:
- Got rid of the
EngScExport request (would have been renamed ExportSchema) because we just pass execution from the ExportDtbase request directly to the Schema object. So the entry-point for that operation is the ExportDtbase request.
- ...but we can't get rid of
EngScImport (to be renamed ImportSchema) because there's no higher-level Dtbase request to act as an entry-point.
- It may be helpful to remember that if we ever want to have an "export single schema" command, we will need an
ExportSchema request to be its entry-point.
Conclusion: we are not going to eliminate EngScImport; it needs to be renamed ImportSchema and normalized to match the Export process to whatever extent seems appropriate.