Hi @gaziyucel,
I see two solutions:
Solution 1: Change the column type in OJS
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 justpublication_settings
. - Adjust the column type in the migration scripts that create these tables during installation (
lib/pkp/classes/migration/install/*.php
andclasses/migration/install/*.php
). - Create a migration script that applies these same changes during upgrade.
- Make the change consistently for all
(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.:
- Usage stats: GitHub - pkp/usageStats at stable-3_3_0
- Static pages: GitHub - pkp/staticPages at stable-3_3_0
You’d be able to create a schema however you like and it wouldn’t be tied to the OJS release process.
Thanks,
Alec Smecher
Public Knowledge Project Team