Remove ADODB

[asmecher]

Remove ADODB.

[asmecher]

PRs:

• pkp/pkp-lib#6264 Remove ADODB #6342 pkp/pkp-lib#6264 Remove adodb #6318
• pkp/pkp-lib#6264 Adapt for ADODB removal ops#78
• pkp/pkp-lib#6264 Adapt for ADODB removal omp#877 [DO NOT merge review report removal!]
• pkp/pkp-lib#6264 Remove ADODB ojs#2905 pkp/pkp-lib#6264 Remove adodb ojs#2897 [DO NOT merge review report removal!]
• pkp/pkp-lib#6264 Adapt for new database toolset reviewReport#38
• pkp/pkp-lib#6264 Adapt for ADODB removal usageStats#35
• pkp/pkp-lib#6264 Adapt for ADODB removal browse#5
• pkp/pkp-lib#6264 Adapt for ADODB removal staticPages#65

TODO:

• Fix search engine cached keyword results feature (Fixed by removing feature -- suspect it was ineffective and would like to solve it separately, e.g. Replace homebrew caching library with 3rd-party caching library #3304)
• Fix (or remove) "create database" installer option (createDatabase in lib/pkp/classes/install/PKPInstall.inc.php) (Opted at least for now for removal: asmecher@cdb0b94)

Highlights/implications:

• Result counts are no longer available automatically when you run a query (e.g. DAOResultFactory->getCount / DAOResultFactory->wasEmpty). It's always been inefficient to both iterate and count, and using Generators (as we will do more in the future) means it's a bad pattern. It's sometimes necessary, though, e.g. for paging.
  • For existing use cases, you can provide the SQL to the DAOResultFactory (e.g. EmailLogDAO::_getByEventType) to allow it to count with a separate query (ADODB used to do this behind the scenes anyway).
  • For future use cases, if counting query results is really needed, try Laravel's Lazy Collections.
  • You will see a DAOResultFactory instances cannot be counted unless supplied in constructor exception if you need to adjust this.
• Retrieving DB results has changed now that ADODB's functions are removed.
  • The DAOResultFactory is still available and works roughly the same, though it should be considered deprecated.
  • Instead, for multiple results, use either
    • ...the patterns in place in the Service classes (which use iterators), or
    • ...you can experiment with Generators (e.g. AnnouncementDAO::getByTypeId), which can be looped through using foreach but don't instantiate the objects it's fetching until they're needed, or
    • ...experiment with a new pattern with Laravel's Lazy Collections
  • For single results, the getters become really short and sweet (e.g. SubscriptionTypeDAO::getById for an object, and ContextDAO::existsByPath for single fields).
• The DAO query functions (DAO::retrieve, DAO::retrieveLimit, DAO::retrieveRange, DAO::update) you're used to are still mostly present, but have some slight behavioural changes:
  • If you are only binding a single parameter to a query, you now need to put it in an array, where ADODB would accept either a literal or an array. (See e.g. ContextDAO::getByPath.) You will see Argument 1 passed to Illuminate\Database\Connection::prepareBindings() must be of the type array if you need to adjust this.
  • $dao->update now returns a count of affected rows, whereas before it returned a success/failure boolean that was frequently misused and undocumented. I have not cleaned up all these cases. See e.g. TemporaryFileDAO::deleteTemporaryFileById. Error conditions should use Exceptions rather than null/false returns that frequently go uncaught.
  • DAO::retrieveCached has been removed pending a suitable replacement (probably a different approach than a query-level cache).
  • However, these functions should be considered deprecated in favour of Laravel's query builder tools. You can either use the patterns set in the query builder classes (these will likely be changed soon) or use the Capsule object to construct queries directly in the DAO. See e.g. AnnouncementDAO::getById.
• The ADODB XML schema management toolset has been removed. This includes the removal of tools/dbXMLtoSQL.php.
  • If you're maintaining a plugin that uses schema management tools, you'll need to convert these to Laravel migrations using tools/xmlSchemaToMigration.php. See Introduce replacement schema management toolset (replacing ADODB XMLSchema) #2493 (comment) for details.

[asmecher]

All PRs merged, not including the testing-purposes-only commits.

[asmecher]

Closing this; there will doubtlessly be related errors but they can either reopen this issue with details or file new entries.