Export - max entries 27

Issues
1

Environment

  • AtroCore 2.2.31 (upgraded from 1.13.53 via 2.0.0 → 2.1.26 → 2.2.31)
  • atrocore/pim 1.15.27
  • atrocore/export 1.10.14
  • atrocore/import 1.10.15
  • PHP 8.4 (Sury repo)
  • Apache 2.4.58, Ubuntu 24.04 LTS
  • MySQL 8.0.45

I did a big update, from 1.13.53 → 2.2.31
The Export Feed deprecated and now moved to Export, so far most is working, but some exports won’t work. Started debugging, after rebuild a 28 rows Export by hand Field and Attribute step by stept, I end up with the conclusion, 27 works, everything abote, Failed. The msg in the database on export_job:
An exception occurred while executing a query: SQLSTATE[HY000]: General error: 1116 Too many tables; MySQL can only use 61 tables in a join

I could upload you also my tl tr claude export, though everything I said above should be enough, at the moment I cannot change to Postgress, we have export-by-Stored-Procedures …

I can’t imagine that export is limited by X Attributes or Fields, there must be some setting, working edit, etc. can someone help?

small-diffs
small-diffs1920×1247 257 KB

diff
diff1920×1200 228 KB

2

In one of the 2.x releases we refactored the Attributes functionality. You can now add attributes to the list view, but the underlying implementation relies on SQL JOINs. MySQL has a hard limit of 61 tables per JOIN, so when too many attributes are included in an export, the query exceeds that limit and fails.

We recommend migrating to PostgreSQL, which does not have this restriction.

1 Like
3

I was afraid something like this was coming. Migrating the DB is one thing, but we also rely on DB routines for data extraction because they’re the fastest approach. Well, OK — thanks a lot for the quick info. I know what we need to do now.
For me and others, Migrate MySQL to PostgreSQL: Migrate from mysql to postgresql

4

In releases 2.3.1-2.3.2, we plan to rework the attribute export so that it works not through JOINS, but through an additional query. Exactly the export. We will leave the output of attributes in the list view as planned. Therefore, if the transition to posgresql is problematic for you, you can wait a few weeks.

But I still recommend switching to posgresql. It is better in many aspects.

5

Great news, thx a lot! Postgresql is planned, but happy if I can schedule that for automn.