2021/11/08/data objects refactoring

Codeblog 2024/11/14 untangling setup calls - mostly just notes to myself 2023/06/04 config classes 2023/05/01 DataPorts redesign 2022/07/21 FutilityCloud process design 2022/08/14 Windows joke I wrote in the late 1900s (on TootCat) 2022/07/21 render-dispatch rubberduckery 2022/07/20 comments on The Home Computer Generation 2022/07/18 layout-event rubberducking 2022/06/24 event-object as output container: the consequences 2022/06/23 event-object as output container: the revision 2022/05/30 more data-class rubberducking 2022/05/20 rubberducking about data classes 2022/01/15 standard CV data format 2021/12/17 The Great Data-Class Restacking 2021/11/25 PHP documentation gripe 2021/11/24 things you can't do in PHP 2021/11/23 PortBank refactoring part 2 2021/11/22 PortBank refactoring part 1 2021/11/08 data objects refactoring 2021/11/05 notes for event-system burndown 2021/07/31 a code mystery 2021/05/31 new PHP wishlist item: first keyword 2021/05/28 a kluge using abstract methods 2021/03/21 PHP wishlist 2020/12/04 (notes) 2020/10/30 (notes) 2020/10/29 (notes) 2020/10/28 (notes) 2020/10/27 (notes: Dovecot on cloud5) 2020/08/29 MediaWiki SpecialPages 2020/08/25 The Plex API 2020/06/12 Ferreteria: thoughts on the Wikcess/flex-data system 2020/04/23 Ferreteria: quick notes on a design issue 2020/04/22 Ferreteria: some thoughts on apps vs. frameworks 2020/02/10 job application (yes, I actually sent this in)

I'm making some changes to the data objects management system for #Ferreteria v0.5.

at present

Database instantiation is currently done by cDatabase::Instantiate(), which uses an internal static table to look up the cDatabase-descendant to instantiate from a slug returned by cDatabaseSpec->GetTypeString().

I suddenly realized that this makes no sense:

• the cDatabaseSpec-descendant should just return the class it wants to use, from ->GetDatabaseClass()
• cDatabaseSpec can instantiate directly, e.g. cMainDBSpec->MakeDatabase().
• cDatabase should be named caDatabase, because it is abstract.

Also, Database-spec-class registration is currently done in ferreteria/data/db/0.php. This made some sense as a stopgap when I wasn't trying to properly handle app-specific databases or db-less tables, but that needs to change.

TO DO

• rename cDatabase to caDatabase
• rename cDatabaseSpec to caDatabaseSpec
• replace abstract caDataSpec->GetTypeString() method with caDatabaseSpec->GetDatabaseClass()
• write caDatabaseSpec->MakeDatabase()
• remove caDatabase->Instantiate()
• add Database registry to csObjects:
  • AddDatabase(string $sSlug, caDatabase $db)
  • GetDatabase(string $sSlug) : caDatabase
• registration of DB-spec classes should happen in a portable overrideable config file -- perhaps in cConfigWeb, in ferreteria/config/portable/defaults.php?

Note that the same database can (and probably should) be registered until multiple names, for easier separation of roles. For example, if the main database is the default database for application tables and also contains the user-access tables, then it could be registered as "*" (default), "main", and "users".