A migration should consider the whole community who will upgrade to the new version of Moodle (and indeed, to the new version of Nwiki). There are from single users to university institutions. The last ones probably have in their databases thousands of entries to migrate (pages, wikis...), and this can be a problem: not only spending too much time migrating from old wikis; server memory could not be enough for such operation, depending on the number of pages.

The solution to this problem is importing wikis and pages dynamically.

Focus on the conceptual model of new nwiki:

• At least, the wiki table must be migrated in the migrate process (all data can be migrated for this table without problem, and this must be done). Further explanations about this migration process can be found below.
• There is a “wiki_instances" table. This table contains wiki identifier for an instance and who are the owner/users/groups availables to use this wiki. Filling this page at migration time would be a problem (lots of users, lots of wikis...). So at first, this table will be empty. The table will be filled dynamically in the following way:
• Every time a user accesses for the first time (after a migration) into a wiki, a wiki_instances tuple will be added into the database.
• “Wiki_pages” is another problem; thousands and thousands of pages. So this table won't be migrated inmediately into the process, too. Every time any user accesses to a page for the first time since the wiki was migrated, it will be migrated. (And synonyms table if it's necessary). That is why the old wiki tables need to be kept. Wiki pages will be migrated using the old wiki_pages tables (probably they will be empty progressively and when the old wiki_pages table is empty, it will be removed.

This is the mainpoint of the migration process.

Now let's see the Wiki table migration:

You can find the code in mod/wiki/db/upgrade.php in the project.

This file only can upgrade from ewiki or from nwiki 1.9. Otherwise, upgrade will not be completed and you will be notified about the problem and recommended to upgrade to nwiki 1.9 first or reinstalling ewiki.

In both cases, old wiki tables will be renamed and new tables installed. Once this is done, the migration of old tables begins. For the upgrade.php, only wiki table will be migrated (because making a full migration would last too much depending on the number of pages and wikis, reasons were explained above).

The migration of wiki table when upgrading from nwiki 1.9 to nwiki 2.0 is quite simple; most fields match in type and concept, so making the relation between fields is direct.

The migration when upgrading from ewiki to nwiki 2.0 is more complex. Some fields are direct, but others aren't. 'wtype' field from ewiki wiki table which says if students must work in groups (group), by their own (student), or they cannot edit the content (teacher). This field has a close relationship with studentmode field from new nwiki 2.0. Depending on the value of groupmode from course_modules table, studentmode value must be 0, 1 or 2:

• 0 = students in group, users can work together.
• 1 = separate students, students work on their own and no one except teacher can see each other work.
• 2 = students visible, students work on their own, but they can see each other.

When wtype is group or teacher, the students must work together (groupmode attribute from course_modules will separate them, not this one), so the value must be 0. If wtype is students, depending on the groupmode attribute, studentmode will have a value of 1 or 2; if groupmode = 0 or 1(no group) then studentmode = 1. Otherwise studentmode = 2.

Another attribute is htmlmode. This attribute describes if the wiki was edited via html code or ewiki parser. It's rather simple.

Finally, in both cases (ewiki and nwiki), in order to avoid running out of memory in server where there are lots of wikis, wiki tuples are retrieved in packets of 100.