2026/01/25
< 2026/01
Jump to navigation
Jump to search
|
Sunday, January 25, 2026 (#25)
|
|
Fixing Connection Clades, part 3
...and now the issue I'm running into is this:
- The object which gets registered (and therefore can be looked up) is a Cable, not an Engine.
- However, it's the Engine Oper object which needs to be able to find the connection to its Engine Conn.
Having written it out like that, I'm no longer sure how to explain the problem...
much later that day...
I'm ending up having to reverse which thing looks up what, when it comes to DbOper and DbConn. ...that is to say, it used to be:
- get the object-slug from
the current DbConn object[1]- via
QSDbConn()QSDbase()which is implemented by the application, because it's set from the user's input (which is interpreted by the application)
- via
- in
FetchDbConn(), look up the current DbConn object from that? Wait, this isn't making sense now...- It's implemented in [WFe]
Sys\Data\Engine\aux\ActionRq\Admin\tToDbConn, in any case...
- It's implemented in [WFe]
- get the current DbOper object from the DbConn object (
ODbOper()⇒QODbOper()⇒FetchDBConn())
...but now:
- get the object-slug from... the current DbConn object, still? (We'll see if that's true...)[1]
- in
ODbOperFind()(fkaFetchDbConn()), find the slug-requested DbOper by looking it up with the Cable class'sObjectRoster(). - Get the DbConn object from the DbOper object (
ODbConn()⇒QODbConn()... I think...)
Footnote
- ↑ 1.0 1.1 Actually, it was always coming from the host-object, which in the current testing is the input-request object implementation in dba. The clade was only named ToDbConn because the DbConn used to be the point of contact; it already included methods for accessing the DbOper as well. I've resolved the issue by renaming it ToDbase – meaning this is the trait to use when you want to connect to a database.