Should module developers directly access the db?

[uaktags]

So one thought that's been on my mind, is should the common module developer access the DB directly, or just access objects that we've already created?

For example: I'm building a bank module, during the installation process I need to add a column to the player_meta table called "bank". I could do something like this (code may be incorrect): $db->execute('ALTER TABLE player_meta ADD bank INT(11) NOT NULL); While this would be quick and easy, they're communicating directly with db, so in the event that anything changes in the structure with player_meta, then this code is invalid. Instead, what if they only communicate the object that is ultimately going to get changed, and let that object decide how it's going to throw it in there:

$pmeta = ezRPG\Players\Meta::addColumn('bank', 'int(11)', no, 0); \\returns boolean In this example of an idea, regardless of how ezRPG's database is handled now or in the future, the module will continue to function.

This idea is also helpful in the event that we modify the "Settings" structure like proposed in another Issue.

ezRPG\Settings\addGroup('GroupName', 'groupslug',<OptionalParentID>); \\returns insertID
ezRPG\Settings\addSetting(<PID>, 'SettingsName', 'SettingsType', 'Value); \\returns boolean
ezRPG\Settings\getAll(<GroupID>)

Something like this means that if we were to break settings away from the inefficient single table it currently is, then all module installers that interact would function. It would be ezRPG engines job to translate the calls, since the developers should HAVE to know how the engine is laied out and does XYZ, they should just be worrying about creating their awesome game.

While all that is good for ezRPG tables, I wouldn't want to stop there though, I'd want to take it a step further for custom tables that they may introduce.

\\During the installation process of a plugin called Analytics
ezRPG\Plugins::setPlugin('analytics'); \\set the current Plugin
ezRPG\Plugins\DB::newTable('login_history');
ezRPG\Plugins\DB::setTable('login_history'); \\set the Table we're working in
ezRPG\Plugins\DB::query('ALTER TABLE <table> ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT,  ADD PRIMARY KEY (id)'); \\<table> is searched for and replaced by the engine to say "login_history"
$ids = ezRPG\Plugins\DB::getAll('id');
$tables = ezRPG\Plugins\DB::getTables(); \\returns an array of available tables owned by this Plugin
ezRPG\Plugins::setPlugin('housing');
$housingtables = ezRPG\Plugins\DB::getTables(); \\returns an array of tables owned by 'housing' 'plugin.'

[deohnas]

Having an abstraction layer for creating and modifying tables seems great to me. I wouldn't necessarily want to limit the developers having access to the database directly though for various reasons such as performance in some cases.

On your example I believe that's another question for introducing module updates that breaks compatibility. Modules and developers should strive not to break backward compatibility once module is in a stable state.

[uaktags]

Yea, the ability to communicate with $db wouldn't be removed, but I don't believe it should be the "preferred" method. Direct access to the db via $container['db'] should be thought more like an "Advanced" low level access for those that need it, but the recommended day to allow new developers adequate entry into our code would be via the above. imho

[ferdis]

Is there a huge demand for such an abstraction layer? I always thought of ezRGP as BYOD(bring your own db). This may complicate that a bit TBH.

[nachfuellbar]

I don't know if i will create new modules (maybe if there is more time) But i think this would be great to become "version independend" to "core" and database

One thing that might bug me is, if there is a performance impact (if it's really small, i don't care)

[deohnas]

Having a small abstraction layer for handling table and alterations seems ok to me. Still quite unsure about abstracting away writing SQL completely though. I'd prefer not. It's quite common with a query builder, but I believe that's mostly used as these frameworks supports different database systems under the hood.

[uaktags]

In away, as Ferdi mention, we aim to allow multiple dbs under the hood.

In my opinion on how this would go, the ability to jump in and do straight SQL would still be there, but for purposes of how to introduce newcomers, we'd point them to using this layer. It'd help them build their first Plugins, making sure that they are bringing in good practices that we set forth. Then as they develop more and dig deeper into our code and our community, they'll ditch the abstraction layer for greater control and integration.