Since we’re already using TEXT, I don’t think there are any real performance impacts going to MEDIUMTEXT instead. (There are one or two places where we’re looking up e.g. publication_id by setting_value, which will be slow, but no slower with MEDIUMTEXT than TEXT.)
However, we don’t have a requirement for this change other than your request, so it would be up to you to make the change. Here’s how you’d do it:
For 3.2.1-x and 3.3.0-x: We’re not making database changes in either of these branches, so you’d need to make and maintain the database change manually. Off the top of my head, there are no migrations that run in that range that would downgrade the column length back to TEXT (potentially chopping off longer content!) but don’t quote me on that. (Test carefully when upgrading.)
For 3.4.0-x and newer, if you’d like to propose this change, please open a pull request:
Make the change consistently for all ..._settings tables, not just publication_settings.
Adjust the column type in the migration scripts that create these tables during installation (lib/pkp/classes/migration/install/*.php and classes/migration/install/*.php).
Create a migration script that applies these same changes during upgrade.
(I know this probably sounds like a lot of work, but it’s not that bad, and I can provide some guidance.)
Solution 2: Use a new table managed by your plugin
There are a few examples of plugins that do this, e.g.:
I thought about solution 2 and discussed this with Dulip also, but this would not be my preferred way. I prefer sticking with the OJS schema and use a custom schema if this is absolutely necessary.
For 3.2.1-x and 3.3.0-x: is there an example of a plugin you know of which makes these changes? This would make my life easier searching.
For version 3.4.0-x, I’ll do so with an pull request. Where can I find this version, is this the main branch of GitHub - pkp/ojs: Open Journal Systems? I will plan to do this at the end of August or in September.
A quick search gave me the following tables which needs to me changed:
Added following method to
“\plugins\generic\optimetaCitations\OptimetaCitationsPlugin.inc.php”:
public function getInstallMigration()
{
import('plugins.generic.optimetaCitations.classes.Install.PluginMigration');
return new Optimeta\Citations\Install\PluginMigration();
}
Added a class as follows to
“\plugins\generic\optimetaCitations\classes\Install\PluginMigration.inc.php”:
namespace Optimeta\Citations\Install;
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Capsule\Manager as Capsule;
class PluginMigration extends Migration
{
/**
* @desc Run the migrations
* @return void
*/
public function up()
{
// publication metadata
Capsule::schema()->create('publication_settings', function (Blueprint $table) {
$table->bigInteger('publication_id');
$table->string('locale', 14)->default('');
$table->string('setting_name', 255);
$table->mediumtext('setting_value')->nullable();
$table->index(['publication_id'], 'publication_settings_publication_id');
$table->unique(['publication_id', 'locale', 'setting_name'], 'publication_settings_pkey');
});
}
}
I don’t recommend making changes to the 3.2.x or 3.3.x core database tables as code to be shipped in a plugin; the database structure for those releases is “frozen” and any changes to those should be undertaken as a DBMS admin task (ALTER TABLE ... in SQL) rather than a part of a plugin.
For 3.4.x, yes, that’s the main branch – it’ll be released late this year or early next. This is where you could propose a pull request that changes setting_value columns to MEDIUMTEXT. At the moment the relevant setting_value columns are defined in these migration classes:
If you are using 3.3.x and want to manually extend a particular column to MEDIUMTEXT by altering it directly in the database, you will not have trouble later upgrading to 3.4.0.
Regards,
Alec Smecher
Public Knowledge Project Team