Calendar 1.0.5 nf_calendar_system_must_be_empty_before_importing

[Alpha1]

A missing phrase.

I cant find the table btw.

 

[Alpha1]

Also: why must it be empty?

 

[Naz]

Fixed, thanks!

I cant find the table btw.

You mean the table that isn't empty? Make sure you don't have any calendars and events if you want to retain keys.

Also: why must it be empty?

If you're retaining keys, the calendar must be empty or else you'll run in to duplicate key issues (i.e. you have an event in vBulletin with the ID of 1 but you also have an event in my add-on with an ID of 1).

 

[Alpha1]

I mean there is no nf_calendar_system table. Maybe I am interpreting the phrase wrong.

If you're retaining keys, the calendar must be empty or else you'll run in to duplicate key issues (i.e. you have an event in vBulletin with the ID of 1 but you also have an event in my add-on with an ID of 1).

IMHO this is not a good method. For example the standard in XenForo and XFMG importers is that you can overwrite data when retaining ID's. I have tested dozens of importers and only a few did not overwrite. The issue that come with importers that do not overwrite are:

1. after each import test, you need to clear the database. Even if it only requires a small adjustment. For example by uninstall & reinstall. For a big board this is a drag. This makes it really time intensive to test and hard to find the details of import data corruption issues.
   
2. there is no way to do incremental import testing.

 

[Naz]

I mean there is no nf_calendar_system table. Maybe I am interpreting the phrase wrong.

nf_calendar is the prefix, system_must_be_empty_before_importing is the rest of the phrase.

IMHO this is not a good method. For example the standard in XenForo and XFMG importers is that you can overwrite data when retaining ID's. I have tested dozens of importers and only a few did not overwrite. The issue that come with importers that do not overwrite are:

1. after each import test, you need to clear the database. Even if it only requires a small adjustment. For example by uninstall & reinstall. For a big board this is a drag. This makes it really time intensive to test and hard to find the details of import data corruption issues.
   
2. there is no way to do incremental import testing.

Both standard XenForo and XFMG importers do the same thing. For example, XFMG importers will throw a warning if you've got media items and want to retain your keys.

public function retainKeysReset()
    {
        $db = XenForo_Application::getDb();

        $mediaCount = $db->fetchOne('
            SELECT COUNT(*)
            FROM xengallery_media
        ');

        if ($mediaCount)
        {
            throw new XenForo_Exception(new XenForo_Phrase('xengallery_gallery_must_be_empty_before_importing'), true);
        }
    }

You don't need to uninstall & reinstall to empty the tables. That'd be tedious as hell. Just run these:

TRUNCATE TABLE xf_nf_calendar_event;
TRUNCATE TABLE xf_nf_event_calendar;

That'll empty all rows in the event and calendar tables.

Perhaps I'm misunderstanding what you mean by overwriting data but I can't say I recall any core importer doing that with retain keys checked and generally, I just follow the core standards.

 

[Alpha1]

That'll empty all rows in the event and calendar tables.

MySQL returned an empty result set (i.e. zero rows). (Query took 0.0108 seconds.)
For both queries.
But the error is gone.

 

[Naz]

MySQL returned an empty result set (i.e. zero rows). (Query took 0.0108 seconds.)
For both queries.
But the error is gone.

MySQL returning an empty result for truncation is normal: MySQL :: MySQL 8.0 Reference Manual :: 13.1.34 TRUNCATE TABLE Syntax

You should be good to go for your import now though.

 

[Alpha1]

That'll empty all rows in the event and calendar tables.

I see that event tags are kept. How do I remove those?

 

[Alpha1]

TRUNCATE TABLE xf_nf_calendar_event;
TRUNCATE TABLE xf_nf_event_calendar;
TRUNCATE TABLE xf_nf_calendar_event_read;

 

[Mouth]

TRUNCATE TABLE xf_nf_calendar_event;
TRUNCATE TABLE xf_nf_event_calendar;
TRUNCATE TABLE xf_nf_calendar_event_read;

If doing that, you should also probably ...
TRUNCATE TABLE xf_nf_calendar_event_watch;
TRUNCATE TABLE xf_nf_event_response;