Upgrading from SQLI Import 1.x
Release 2 keeps every 1.x handler, setting, table, policy and page working. Nothing of 1.x is deleted.
Contents
Steps
Back up the database.
Install 2.x over 1.x and activate expqueue and expui (Getting started).
Create the tables:
./console ext:expqueue:install-schema ./console ext:sqliimport:install-schemaSee what the migration would do. Nothing is changed:
./console ext:sqliimport:migrate-1xMigrate. Add
--rolesto give every role withsqliimport/manageimportsthe policysqliimport/manage(Manage imports) with the same handler limitation:./console ext:sqliimport:migrate-1x --apply --rolesReplace the 1.x cron parts with
expqueueandsqliimport, both every minute (Schedules and cron).
What the migration does
| Part | Result |
|---|---|
| Handlers | Each 1.x handler becomes an import with the identifier legacy-<handler> |
| Scheduled imports | Each becomes an import with its options and a schedule of the same frequency. The 1.x scheduled import is switched off, not removed. |
| History | Past 1.x import requests become read-only runs (status, time, user) |
Roles (--roles) | Roles with manageimports get manage (Manage imports) with the same handler limitation. Roles with only listimports need nothing new: listimports still lets them look at the Imports tab. Roles with sqliimport/* are left alone. |
The migration can be run again; what was migrated before is left alone. Pending 1.x import requests are started as
real runs by the cron part sqliimport.
What changes
Imports are edited in the import editor (The import editor). A migrated import of a 1.x handler has the steps source, processing, schedule and review.
Two policies control access: Manage imports (
manage) and Run imports (run).manageimportsstill counts as Manage imports, andlistimportslets a user look (Getting started).1.x handlers run untouched on the job queue. Their records have the outcome "Processed (1.x)", and their progression notes go to the run's log. Retrying only failed rows and undoing a run are not available for them.
The 1.x pages are part of the 2.x pages, and the left menu no longer has a group "sqliimport 1.x":
1.x page Where it is now sqliimport/items(the import requests)The dashboard sqliimport/list, section "1.x import requests", with Cancel and Interruptsqliimport/addimport(request an import)The form Request import in that section sqliimport/purgelistPurge history in that section sqliimport/scheduledlist,sqliimport/addscheduledsqliimport/schedules, section "1.x scheduled imports"the progress of a request the run page sqliimport/run/<id>The old addresses keep working: they redirect to the new pages, and a POST with the fields of 1.x still does what it did, so scripts that post there need no change. The actions are POST forms with a confirmation.
One import no longer blocks the others: 1.x had one global lock, 2.x runs different imports in parallel.
New in 2.0 for every import, the migrated ones too: dry runs, the live run page, notifications and statistics (Imports and runs). A 1.x handler that only copies fields from a file into a class can be replaced by a source and a no-code mapping, which also brings undo and the conflict rules.
Fixed 1.x bugs
On Exponential 6, release 2 fixes these 1.x bugs:
- The fields of 1.x import requests and scheduled imports read as empty, because their getter bypassed the kernel's persistent storage, so the 1.x list and cron job saw nothing.
- Options serialized with NUL bytes were cut on SQLite.
- Option text with a line without "=" warned on PHP 8.
The extension manual has the full migration page, including how to replace a simple 1.x handler with a no-code
mapping: /exphelp/viewer/ext/sqliimport/migration-1x.md (German: /exphelp/viewer/ext/sqliimport/ger-de/migration-1x.md).