Dynamic introduction of [actorRelations] within [QubitActor] is not allowed

[Jeremy]

Greetings,

We recently upgraded to AtoM 2.6 (along with the necessary MySQL upgrade), and encountered an indexing problem within the first day. Everything seems to index fine outside of our actors, which results in the following at the 500th description:

Error in one or more bulk request actions:

  index: /atom/QubitActor/433 caused mapping set to strict, dynamic introduction of [actorRelations] within [QubitActor] is not allowed

I followed through the instructions on this thread - https://groups.google.com/u/1/g/ica-atom-users/c/IPa4BVHS2yI/m/gvtJfT4eEwAJ - and I am still getting the same result. We are running Linux (RHEL7). Our MySQL settings are as follows:

| @@sql_mode                                                                                                            | @@GLOBAL.SQL_MODE                                                                                                     |
+-----------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------+

I've also checked our nginx/error.log, and there is nothing even registered as being an issue. Clicking on any one of the authority records results in Elasticsearch error: Elastica\Exception\ResponseException on the browser.

Is there anything further we could do to correct this?

Thanks in advance!

Jeremy

[Dan Gillean]

Hi Jeremy, 

We've run into some issues using the STRICT_TRANS_TABLES mode with AtoM and MySQL 8.0. While we intend to investigate and resolve these issues internally long-term (see issue #13331), for now, our installation documentation recommends only using the following SQL modes. From the docs: 

Finally, let’s configure our MySQL modes. The MySQL server can operate in different SQL modes, which affects the SQL syntax MySQL supports and the data validation checks it performs. We’ll add our preferred mode settings in a new file.

First, let’s create a new file with our SQL modes.

Paste the following values in a new file at /etc/mysql/conf.d/mysqld.cnf and save:

[mysqld]
sql_mode=ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
optimizer_switch='block_nested_loop=off'

Now we’ll restart MySQL:
sudo systemctl restart mysql

See:  https://www.accesstomemory.org/docs/2.6/admin-manual/installation/linux/ubuntu-bionic/#mysql

I suspect that this will resolve the issues. Don't forget to check your session SQL mode values too! See: 

• https://www.accesstomemory.org/docs/2.6/admin-manual/maintenance/common-atom-queries/#check-server-sql-modes  
  

 Cheers, 

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/21dd13f6-dd45-4ba6-8ced-dd55b13236ben%40googlegroups.com.

[José Raddaoui]

Hi Jeremy,

Apart from what Dan says, I wonder if the search index was recreated during the upgrade:

https://www.accesstomemory.org/en/docs/2.6/admin-manual/installation/upgrading/#rebuild-search-index-and-clear-cache 

Best regards,

Radda.

[Jeremy]

Thanks so much for the quick replies, Dan and Radda! Unfortunately, after following the instructions you both provided, we still end up with the same error. I have tried to look at whether we needed any cleanup of unlinked authority records, for example, or to see whether any of the data in the actor_i18n table could be affecting our indexing. From what I could tell, there is nothing in particular that should cause any problems. Might you have any further suggestions for what we can do?

Thanks again!

Jeremy

[Dan Gillean]

Hi Jeremy, 

I'd probably suggest that you make a back up of the database, and then run the tools:purge task, drop/recreate it the db, and  then reload your data and try the upgrade task again (as per the upgrade docs). I'm wondering if perhaps some of the schema migrations didn't execute properly because of the unexpected sqlmodes - hopefully running it again (and restarting services after) might help?

Let us know how it goes!

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/594d703b-3afe-4adf-9e43-ee79f7c647c7o%40googlegroups.com.