[Koha-bugs] [Bug 23073] wiki.koha-community.org needs updating to a later version

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23073

--- Comment #6 from Thomas Dukleth <td-koha-bugs at agogme.com> ---
I am preparing scripts to automate the conversion of the Koha MediaWiki
database from Postgres to MySQL.

Multiple methods for reproducing the MediaWiki Postgres database from different
forms of dump files are working well.  Using the full dump gives me more
confidence with the requirement that more preparation of database users and
associated username databases is necessary to avoid errors.  The Postgres
database restoration with the separate SQL structure and dump files require
constraint options such as --data-only --disable-triggers --superuser to avoid
errors with pg_restore.

Philipp Spitzer's psqltomysql.py is written in a very generic abstracted matter
and easy to modify with a few changes for both his database names, usernames,
and adjustmemts where in Postgres we do not have the conventional form of
username is the same as database name,  
http://www.winterrodeln.org/trac/browser/servermediawiki/trunk/pgsqltomysql/pgsqltomysql.py
.

The are a few problematic MediaWiki Postgres database tables for migration to
MySQL where an obvious generic or MySQL centric SQL structure file is not
present.  It may be necessary to partly convert from the Postgres SQL structure
dump.

Table anonymized_mwuser is owned by one particular database username which
might be a legacy from the very first day of testing MediaWiki for Koha for
which I started over the next day.  All other tables have a different common
username for the owner.  I have not found any proper source for the
anonymized_mwuser table.

I have not found an easy to use MySQL structure file for the Semantic MediaWiki
tables which have been essentially unused in consequence of Semantic MediaWiki
not being well supported with Postgres.  Semantic MediaWiki was released with
SMW_Postgres_Schema.sql but no corresponding MySQL centric file unlike other
extensions which add SQL tables.  MySQL Semantic MediaWiki tables seem to be
built from the Semantic MediaWiki installation script but that cannot be run on
an empty database for the structure and I have not found an obvious database
structure component in the includes files in the code.  A workaround for
preserving any existing data is to retrieve the structure from a MySQL SQL
structure dump after installing Semantic MediaWiki on an otherwise empty MySQL
based MediaWiki installation being careful of course to match the old versions
we have for successful database migration.  A similar workaround might be to
temporarily drop the Semantic MediaWiki tables from the temporary Postgres
database restoration; reinstall Semantic MediaWiki from the working MySQL
conversion where no Semantic MediaWiki tables have been converted; dump the
MySQL SQL structure; and then completely restart the database conversion using
a newly restored temporary Postgres database and the newly obtained MySQL SQL
structure dump.  We might always choose not to preserve Semantic MediaWiki data
under the presumption that there was no significant work done to make use of
Semantic MediaWiki under Postgres where it would not work well: drop the
Semantic MediaWiki tables from database conversion; uninstall Semantic
MediaWiki; and then start again with Semantic MediaWiki by installing Semantic
MediaWiki with no pre-existing Semantic MediaWiki data after upgrading
MediaWiki to the current version in MySQL.  The non-preservation option for
Semantic MediaWiki might be best given known limitations of Semantic MediaWiki
under Postgres, the peculiar dichotomy with how Postgres is treated, and the
potential importance of Semantic MediaWiki for a flexible faceted system for
finding content.

-- 
You are receiving this mail because:
You are watching all bug changes.