Search indexing fails to parse

[Toni Schoenbuchner]

Dear atom users and devs,

I'm trying to populate my search php /atom/src/symfony search:populate but failing with

 Error in one or more bulk request actions:                                

  index: /atom/QubitRepository/448 caused failed to parse [i18n.languages]

Can one help what could go wrong and how to get further log output to find the problem?

thanks a lot,

Toni

[Toni Schoenbuchner]

Okay so I've found what is going wrong. I've followed this conversation to delete a translation (https://groups.google.com/g/ica-atom-users/c/55GENtGjp-Q/m/51uMq65MBQAJ) while this is working nicely for archival descriptions it does not if the slug refers to an archive. My guess is that some foreign key still links to the deleted Spanish entry and that's why the indexing is failing.

So what I did is: dump all data and "grepped" for culture "es" which can only be found in "property_i18n" . Does this makes sense to clear those DELETE * from property_i18n pin WHERE culture  = "es"

What is property_i18n used for?

(By the way, this is all a test VM. So no danger to break anything ;)

[Toni Schoenbuchner]

Unfortuantely this did not make it working . So elasticsearch is working on informationObjects when failing to insert. Thankful for any hint what else I can try.

[Toni Schoenbuchner]

For the record. This is what finally fixed it for me:

DELETE a FROM repository_i18n a

JOIN repository ON repository.id = a.id

WHERE a.culture = "es";

So if I could put something on a wish list than it is that users can delete translations without deleting the whole entry asking the tech stuff dancing with the database :))

[Dan Gillean]

Hi Toni, 

Sorry for the delay in following up, and for the issues you've encountered. Thank you for updating the thread and letting us know the solution that you found! 

I agree that in the future, as part of improvements to the internationalization support in AtoM, there should be a way via the user interface to delete translations without deleting the original record. 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/edfd6b29-cdc9-42a0-814b-247b196ec47fn%40googlegroups.com.

[Toni Schoenbuchner]

Hi Dan,

no worries at all for any delay ;) You helped me beyond measure by sharing your knowledge in many threads.

Best,

Toni

[tat...@gmail.com]

Hi group.

My error is a little bit different:

PHP Fatal error:  Uncaught Elastica\Exception\Bulk\ResponseException: Error in one or more bulk request actions:

index: /atom/QubitRepository/1102 caused failed to parse
 in /usr/share/nginx/atom/vendor/composer/ruflin/elastica/lib/Elastica/Bulk.php:410

Does anyone knows what should I do?

Thanks,

Tatiana Canelhas

[Dan Gillean]

Hi Tatiana, 

In the last case, it was an issue of data corruption - in that case, a translation that had been orphaned. I suspect that while the precise reason may be different, the underlying root cause is likely similar. 

As such, I would recommend that you start by running the example query we have in the docs to look for common data corruption issues: 

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/troubleshooting/#dealing-with-data-corruption
  

To access the MySQL command prompt so you can try running this query, see: 

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/common-atom-queries/#accessing-the-mysql-command-prompt
  

And of course, if you end up making any changes, making a backup first is always a good idea: 

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/common-atom-queries/#backing-up-the-database
  

Keep in mind however that this query primarily finds issues with archival descriptions, while the error message suggests that the problem may be associated with an Archival Institution (i.e. a repository record). 

Have you tried running any of the common maintenance tasks, particluarly those listed on the Troubleshooting documentation page? For example: rebuilding the nested set, generating slugs, clearing the application cache, restarting PHP-FPM... these are all good things to try, as they can resolve many common issues. 

Does your instance have many repository records? Perhaps you could do some manual review of them, to look for issues. If there are translations, are they entered on the right template, and is culture fallback working as expected? Do you see any cases with strange characters that might not be UTF-8? What happens if you try adding all the repository records to the clipboard and attempting a CSV export?

If you are still having issues, please be sure to send us more information as well, such as: 

• Full version number listed in Admin > Settings
• Whether you followed the recommended installation instructions for your version - and if not, what changes you have made
• Whether you upgraded recently or not
• Whether you have any local customizations, including a custom theme
• Anything further about the lead up to or cause of the issue that will help us understand what might have happened
• What you have tried to resolve the issue so far
• etc

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/9b1f9356-60dc-4379-a2cf-7ff6793f647fn%40googlegroups.com.