-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adopt the stellarwp/db library (version 1.1.0) #5
Conversation
* @see https://github.com/BrianHenryIE/strauss | ||
*/ | ||
|
||
$aliases = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The class_alias
function will pre-load the aliased classes when you call it. Not an issue in this specific application, but something to note/share when eager-loading of the classes is not a desirable side effect. The solution to keep lazy-loading aliased classes is to do so in an autoload function.
This PR builds on top of the original PR (#5) to add the DB library into the mix. Within you will find: 1. Removal of the `di52` library. Instead, `StellarWP\Schema\Config::set_container( $container )` must be used. 1. I've refactored some of the `di52`-specific features (service providers, `getVar`/`setVar`, etc ) to be more friendly to other containers that implement the core `singleton()`, `make()`, and `bind()` methods. 1. I've removed the `stellarwp/db` as an included library. Instead, the project that uses `stellarwp/schema` should inject the `DB::class` via `StellarWP\Schema\Config::set_db( DB::class )` Note: I imagine further iterations on this code will be needed before we merge it fully.
This changeset adopts the stellarwp/db library and uses it for database operations.
$wpdb
calls with theDB
class.Addresses: #7