Attribute Tag counts wrong after migration

Permalink
I have recently migrated a site from 5.6.3.5 to 5.80. All seems to have gone ok, there were a few issues with having to replace problog with another package.
I have today identified an issue with the migrating of Tags. All of the tags have imported and are still associated with the correct page item, but when the migration imported the tags it created duplicate entries in the atSelectOptions table, when you try to get a tag usage count for a particular tag it is reporting 1 when there are multiples. I have done some testing by adding new tags into the site and for these the usage count is correct. I have also tried adding an existing tag into another page but that results in another entry in atSelectOptions and a count of 1 showing up multiple times. This is the code I am using to display the list and count

<ul class="tms-tag-list blog tags">

<?php
$ak = CollectionAttributeKey::getByHandle('tags');
$akc = $ak->getController();
$pp = false;

$tagCounts = array();

$ttags = $akc->getOptionUsageArray($pp);


$tags = array();
foreach($ttags as $t) {
$tagCounts[] = $t->getSelectAttributeOptionUsageCount();
$tags[] = $t;
}
shuffle($tags);

for ($i = 0; $i < $ttags->count(); $i++) {
$akct = $tags[$i];
$qs = $akc->field('atSelectOptionID') . '[]=' . $akct->getSelectAttributeOptionID();
echo '<li><a href="/ns/written-source-communications/written-source-communication-search-results/?'.$qs.'">'.$akct->getSelectAttributeOptionValue().'<span class="postCount">'.$akct->getSelectAttributeOptionUsageCount().'</span></a></li>';
}

?>
</ul>

I am open to either changing this code to correctly show the count or fixing the underlying data,

Thanks
Martyn

FaganSystems
View Replies:
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
I would run this query on the database and then export the results
SELECT DISTINCT * FROM atSelectOptions;

Then drop the existing atSelectOptions table and import the new table..
You could also rename the existing atSelectOptions table instead of dropping it, this would allow you to get back to where you started if things go wrong.
To be on the safe side I would also export the entire database first.
chawilaclef replied on at Permalink Reply
chawilaclef
a UNIQUE sql field set may solve it but you should keep c5 db structure virgin.
FaganSystems replied on at Permalink Reply
FaganSystems
HI
I ended up changing the code that rendered the list to remove duplicates, this seems to have worked well and isn't causing much speed impact.

Martyn