As designed \XF\Import\Data\EntityEmulator is not compatiable with columnAliases

[Kirby]

Affected version

2.1.0 Beta 4

\XF\Import\Data\EntityEmulator does not seem to work with columnAliases

 

[DragonByte Tech]

You should be using \XF\Import\Data\AbstractEntityData if you need actual entities.

See the Admin importer:

<?php

namespace XF\Import\Data;

class Admin extends AbstractEntityData
{
    public function getImportType()
    {
        return 'admin';
    }

    public function getEntityShortName()
    {
        return 'XF:Admin';
    }
}

Though AbstractEntityData is bugged beyond belief:
\XF\Import\Data\AbstractEntityData :: write doesn't return new ID
\XF\Import\Data\AbstractEntityData :: preSave - retainIds call is wrong
\XF\Import\Data\AbstractEntityData :: preSave - retainIds needs to set PK using forceSet

So you will probably want to create your own abstract class that extends AbstractEntityData like so:

<?php

namespace Your\Namespace\Import\Data;

use XF\Import\Data\AbstractEntityData;

abstract class AbstractEntityDataFixed extends AbstractEntityData
{
    /**
     * @param $oldId
     *
     * @return null|void
     */
    protected function preSave($oldId)
    {
        $entity = $this->entity;
        
        $primaryKey = $this->primaryKey;
        
        if (!$entity->isChanged($primaryKey))
        {
            if ($this->retainIds() && $oldId !== false)
            {
                $entity->set($primaryKey, $oldId, ['forceSet' => true]);
            }
        }
    }
    
    /**
     * @param $oldId
     *
     * @return string|null
     * @throws \XF\PrintableException
     */
    protected function write($oldId)
    {
        $this->entity->save();
        
        return $this->entity->getIdentifier();
    }
}

Fillip

 

[Kirby]

XFI uses EntityEmulator so this issue popped up when we imported a vB 4.2 into XF 2.1

 

[DragonByte Tech]

Then I misunderstood, maybe if you added some more information (such as how this is a problem, what exactly failed, what errors did you get, etc) it would help others understand the error and help the devs fix it


Fillip

 

[Kirby]

Yeah, probably - was kinda lazy to provide taht info and implicity assumed XF devs would automatically know

 

[DragonByte Tech]

So if someone uses the contact us on your website and says "posting doesn't work" you automatically know which member it is, which forum they were trying to post in, which thread they were trying to post in and whether the issue is a permissions issue or something else?




Fillip

 

[Mike]

Generally, I'm going to say that this is mostly as designed. The import system still needs updates for the reaction system changes, which is essentially what you're reporting.

The alias system is mostly designed around a stopgap to reduce BC issues when reading existing data. We don't use it on writes, as this may cause deeper issues (potentially including invalid data due to expanded data structures).

 

[Kirby]

@Mike
Thanks for the reply, but the whole point of XF\Import\Data\LikedContent is to write to that entity, isn't it?
How is that supposed to work if the column aliases are not taken into account?

As far as I can see, this would mean that the calling code would have to set the new columns which does not seem to make much sense to me if the entity is for backwards compatibilty which clearly is not achived if the column names have to be adjusted.

Would be nice to get some more feedback on this

 

[Chris D]

The XF:LikedContent entity only exists as a compatibility layer between XF 2.0 and XF 2.1 code. The columnAliases feature was added so that if you try to read data then it doesn't catastrophically fail.

For example, it is possible to upgrade to XF 2.1 while still running XFMG 2.0. XFMG has no idea about reactions, but it does make use of likes and therefore when dealing with the reading element of the like system, it very much needs to map the old column names to the new column names in the new xf_reaction_content table, otherwise XFMG would be totally broken until it is upgraded to 2.1.

This compatibility layer only needs to exist on reading because any code responsible for liking content still exists, but has been mapped through to the relevant new reactions methods. We don't need to alias the columns for writing so we're not going to.

Importing is the exception but it's not a significant enough issue that we will be aiming to add a compatibility layer for. We'll simply release an XF 2.1 compatible version of XFI when the time is right which will use the ReactionContent handler instead of LikedContent.

 

[DerTobi75]

We'll simply release an XF 2.1 compatible version of XFI when the time is right which will use the ReactionContent handler instead of LikedContent.

Any chance that the time is right, now?!

 

[Chris D]

There's actually only a couple of changes required in the code to make it work right now.

You need to edit the file src/addons/XFI/Import/Importer/XenForo2.php.

Find:

'like_date'

Replace with:

'like_date' => 'reaction_date'

And find:

$import->like_user_id = $likeUserId;

Replace with:

$import->reaction_user_id = $likeUserId;

And/or edit the file: src/addons/XFI/Import/Importer/vBulletin.php.

Find:

'like_user_id' => $likeUserId,
'like_date' => $reputation['dateline'],

Replace with:

'reaction_user_id' => $likeUserId,
'reaction_date' => $reputation['dateline'],

Alternatively there are changes to attempt to main backwards compatibility in the next 2.1 release.

 

[DerTobi75]

Great, going to test this tomorrow! Thank you

 

[DerTobi75]

Hi Chris,

There's actually only a couple of changes required in the code to make it work right now.

You need to edit the file src/addons/XFI/Import/Importer/XenForo2.php.

Find:

'like_date'

Replace with:

'like_date' => 'reaction_date'

Did you really mean

Replace with:

'like_date' => 'reaction_date'

or does it has to be:

Replace with:

'reaction_date'

Tobi

 

[Chris D]

I really meant that, but it depends, heh.

If you're importing from XF 2.1 then it needs to be:
Replace with:

'reaction_date'

But if you're importing from XF 2.0 then it needs to be:
Replace with:

'like_date' => 'reaction_date'

What I neglected to mention is that in the next XFI release there is actually a dedicated XenForo21 importer. So if you're importing from XF 2.0 then you will use XenForo2 as you do now, but if you're importing from XF 2.1 then you will use XenForo21. The key differences are the XenForo21 importer handles importing reactions (rather than just likes) and bookmarks.

 

[DerTobi75]

Ah, I am importing from vBulletin 3.8 into XF 2.1.

 

[Chris D]

Oh, well then you don't need to make any changes to the XenForo2 file

You just want this bit:

And/or edit the file: src/addons/XFI/Import/Importer/vBulletin.php.

Find:

'like_user_id' => $likeUserId,
'like_date' => $reputation['dateline'],

Replace with:

'reaction_user_id' => $likeUserId,
'reaction_date' => $reputation['dateline'],

 

[DerTobi75]

Finally I ran into this MySQL Error:

XF\Db\DuplicateKeyException: MySQL query error [1062]: Duplicate entry 'post-61480-9' for key 'content_type_id_user_id' in src/XF/Db/AbstractStatement.php at line 217

Maybe I better have to wait for the released 2.1 importer?!

 

[Chris D]

I think you’re running into this:

Fixed - vB v4.2.3 [XF\Db\DuplicateKeyException] on Positive Reputation

What is the best way to get around this? [XF\Db\DuplicateKeyException] MySQL query error [1062]: Duplicate entry 'post-272801-599' for key 'content_type_id_like_user_id' I see there is a similar post here...

xenforo.com

There is a reasonable workaround there which should get you through until we implement a proper fix.