Ferreteria/v0.6/clade/Sys/Data/Engine/aux/ActionRq/Admin/ToDbOper: Difference between revisions

From Woozle Writes Code
< Ferreteria‎ | v0.6‎ | clade‎ | Sys‎ | Data‎ | Engine‎ | aux‎ | ActionRq‎ | Admin
Jump to navigation Jump to search
No edit summary
No edit summary
Line 3: Line 3:
! colspan=3 | Clade Family
! colspan=3 | Clade Family
|-
|-
| align=right | {{l/ver/clade|Sys\Data\reqs\Engine|AdminRq}}
| align=right | {{l/ver/clade|Sys\Data\reqs\Engine\ActionRq|Admin}}
| &rarr; {{l/ver/clade|Sys\Data\reqs\Engine\ActionRq\Admin|ToDbOper}}
| &rarr; {{l/ver/clade|Sys\Data\reqs\Engine\ActionRq\Admin|ToDbOper}}
|
|

Revision as of 14:06, 26 September 2025

clade: Sys\Data\Engine\aux\ActionRq\Admin\ToDbOper
Clade Family
Admin ToDbOper

EngDbExport
EngDbScList
EngDbSetup
EngDbTest
EngDbUConf

Clade Aliases
Alias Clade
Base* [c,i] AdminRq
DbOper* [i] Ops
QStr* [i] Str

About

The caToDbOper class needs to know how to find a Database Operations object from a db name-slug, but can't know where that slug is specified. The QDbConnSlug() function, which returns the value/status of that parameter, is therefore abstract. The same is true of the Schema name-slug. It is up to descendant classes (generally found within application code) to define where those slugs can be found, and return a value/status string object for each.