XF 2.0 Mass updates/changes

[Snog]

I've taken a stance in XF 2 that I won't modify any xenforo tables directly unless absolutely necessary. Unfortunately that means when someone upgrades from XF 1 to XF 2 there could be massive amounts of data that needs to be transferred to new tables.

Currently I'm using cron tasks to do this, which limits the number of records transferred at once, but that can take quite a bit of time to finish on larger sites.

For example, an add-on has data in the old XF 1 post table, and it needs to be moved to a new table in XF 2. There could in theory be a million posts that need to have the data moved to the new table.

Is there a better way to do this during install/upgrade that I might have missed and still prevent timeouts during install?

 

[Snog]

Nevermind... StepResult.

 

[Chris D]

It's worth bearing in mind that we don't necessarily say that core tables should never be modified. We just have some recommended conventions before you do.

• Always ensure a column added to a core table either has a default value or is nullable (if your add-on is disabled, the entity won't write a default value).
• Always ensure a column added to a core table is prefixed with something that identifies either the developer or the add-on (essentially something that XF wouldn't ever use...)
• Avoid changing the definition of a default column in a core table

In addition new tables should of course also be prefixed with a reasonable name to avoid clashes with tables we might add in the future.

As long as the above is followed, there shouldn't be any issue. You have to weigh up whether the complexity and potential performance overhead of storing stuff in an additional table is actually worth it (often it won't be).

 

[Snog]

When I say 'unless absolutely necessary' it boils down to 'if it's used everywhere'.

 

[Snog]

I almost forgot. I could be wrong, but I recall seeing something about XF2 having the ability to reset it's database tables to default. Wouldn't that mean that any custom columns would be lost if that were to happen?

 

[Chris D]

Are you thinking of this?

The schema manager change system will now identify conflicting tables or columns and rename them instead of stopping with an error. If this happens, an entry will be added to the server error log.

That's all about rectifying the mistakes made by not using the best practices I listed above. We wouldn't do anything to reset a table though.

 

[Snog]

No, I thought I saw something way back that referenced it, but my memory may be confusing it with xf:install --clear which deletes all of the tables anyway.