NEW Add method to check if a class is ready for db queries

[GuySartorelli]

This effectively makes the functionality from Security::database_is_ready() reusable for any arbitrary DataObject subclass.

Replaces #10276

I've resurrected this old PR because I was about to reimplement "is the DB ready?" checks yet again in #11783.... I'd much rather just reuse existing logic instead.

Parent issue

• Have a consistent API for confirming if a DataObject is ready for database operations #10332

[beerbohmdo]

Maybe this should be a new issue but it is somewhat related: For me the existing Security::database_is_ready sometimes failes with an error.

I don't know why but the $schema->tableName($class) returns null in some cases (presumably a race condition with the cache) and ClassInfo::hasTable($table) don't check for that, what results into an error.

[GuySartorelli]

@beerbohmdo Please open a new issue about that bug - a patch for that likely needs to target CMS 5 first, while this new method is for CMS 6. I'll also want some more details about how to reproduce it etc - all of which is best captured in an issue.

[emteknetnz]

Feels like this method should not be on DataObjectSchema, which "Provides dataobject and database schema mapping functionality"

Seems like this method should be on DB instead which has "Use this class for interacting with the database."

[GuySartorelli]

Feels like this method should not be on DataObjectSchema, which "Provides dataobject and database schema mapping functionality"

Seems like this method should be on DB instead which has "Use this class for interacting with the database."

In the original PR I had it in DB - but that felt wrong because DB doesn't know anything about DataObject, and the logic here is explicitly checking if the database is ready _based on the schema of the DataObject`_.
See #10041 (comment)

In other words, while we are using DB to "interact with the database" as per that class's intention, we are only doing so to check if the database is ready according to "database schema mapping" as per the DataObjectSchema class's intention.

[emteknetnz]

Seems like DBSchemaManager would be a better place for this?

That already has a private property Database $database - which presumably is the same object (singleton??) that DB::get_conn() uses, which is used in things like DB::is_ready().

DB::get_schema() (used by DB::field_list()) presumably returns the same (singleton?) DBSchemaManger?

[GuySartorelli]

DBSchemaManager doesn't know about DataObject schema specifically though.
Note that the implementation that I've currently got calls the following DataObjectSchema methods:

• tableName()
• databaseFields()

I think it makes more sense for a higher-level class (DataObjectSchema, which knows about the DataObject) and can call down to lower-level API as needed, rather than having it in a lower-level class (DBSchemaManager which is for abstracting out DB schema management to different SQL server implementations and doesn't know anything about DataObject) call up to higher-level API.