Hello,
It seems that your server does not support MEMORY engine, which is neded for Finder (Smart search component) to work.

If you do not use search on your site you can disable Content => Finder plugin.

Yes my server doesn't support MEMORY engine, but i read on the joomla forum that innodb table would work, slower but works.

Is there a way to choose the type of the engine for the search function ?

Claudio

TBH I do not know about such posibility

ALTER TABLE my_table ENGINE = InnoDB;

should work

The problem is all the tables show ENGINE = Innodb, bone is 'Memory' and all the search features works with no error, the erro appears only when an article is modified, but repeat the modifies will be saved but this error appears

This is the DB tables and the engine

mysql> SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'dbname';
+-------------------------------------------+--------+
| TABLE_NAME | ENGINE |
+-------------------------------------------+--------+
| esperto | InnoDB |
| help | InnoDB |
| j42023_action_log_config | InnoDB |
| j42023_action_logs | InnoDB |
| j42023_action_logs_extensions | InnoDB |
| j42023_action_logs_users | InnoDB |
| j42023_ak_acl | InnoDB |
| j42023_akeeba_common | InnoDB |
| j42023_akeebabackup_backups | InnoDB |
| j42023_akeebabackup_profiles | InnoDB |
| j42023_akeebabackup_storage | InnoDB |
| j42023_assets | InnoDB |
| j42023_associations | InnoDB |
| j42023_banner_clients | InnoDB |
| j42023_banner_tracks | InnoDB |
| j42023_banners | InnoDB |
| j42023_categories | InnoDB |
| j42023_chronoengine_acls | InnoDB |
| j42023_chronoengine_extensions | InnoDB |
| j42023_chronoengine_forms6_blocks | InnoDB |
| j42023_chronoengine_forms6_datalog | InnoDB |
| j42023_contact_details | InnoDB |
| j42023_content | InnoDB |
| j42023_content_copia | InnoDB |
| j42023_content_edit1 | InnoDB |
| j42023_content_edit2 | InnoDB |
| j42023_content_frontpage | InnoDB |
| j42023_content_old | InnoDB |
| j42023_content_rating | InnoDB |
| j42023_content_test1 | InnoDB |
| j42023_content_types | InnoDB |
| j42023_contentitem_tag_map | InnoDB |
| j42023_convertforms | InnoDB |
| j42023_convertforms_campaigns | InnoDB |
| j42023_convertforms_connections | InnoDB |
| j42023_convertforms_conversions | InnoDB |
| j42023_convertforms_submission_meta | InnoDB |
| j42023_convertforms_tasks | InnoDB |
| j42023_convertforms_tasks_history | InnoDB |
| j42023_core_log_searches | InnoDB |
| j42023_extensions | InnoDB |
| j42023_fields | InnoDB |
| j42023_fields_categories | InnoDB |
| j42023_fields_groups | InnoDB |
| j42023_fields_values | InnoDB |
| j42023_finder_filters | InnoDB |
| j42023_finder_links | InnoDB |
| j42023_finder_links_terms | InnoDB |
| j42023_finder_logging | InnoDB |
| j42023_finder_taxonomy | InnoDB |
| j42023_finder_taxonomy_map | InnoDB |
| j42023_finder_terms | InnoDB |
| j42023_finder_terms_common | InnoDB |
| j42023_finder_tokens | InnoDB |
| j42023_finder_tokens_aggregate | InnoDB |
| j42023_finder_types | InnoDB |
| j42023_history | InnoDB |
| j42023_languages | InnoDB |
| j42023_mail_templates | InnoDB |
| j42023_menu | InnoDB |
| j42023_menu_types | InnoDB |
| j42023_messages | InnoDB |
| j42023_messages_cfg | InnoDB |
| j42023_modules | InnoDB |
| j42023_modules_menu | InnoDB |
| j42023_newsfeeds | InnoDB |
| j42023_nextend2_image_storage | InnoDB |
| j42023_nextend2_section_storage | InnoDB |
| j42023_nextend2_smartslider3_generators | InnoDB |
| j42023_nextend2_smartslider3_sliders | InnoDB |
| j42023_nextend2_smartslider3_sliders_xref | InnoDB |
| j42023_nextend2_smartslider3_slides | InnoDB |
| j42023_overrider | InnoDB |
| j42023_postinstall_messages | InnoDB |
| j42023_privacy_consents | InnoDB |
| j42023_privacy_requests | InnoDB |
| j42023_redirect_links | InnoDB |
| j42023_scheduler_tasks | InnoDB |
| j42023_schemas | InnoDB |
| j42023_session | InnoDB |
| j42023_tags | InnoDB |
| j42023_template_overrides | InnoDB |
| j42023_template_styles | InnoDB |
| j42023_ucm_base | InnoDB |
| j42023_ucm_content | InnoDB |
| j42023_update_sites | InnoDB |
| j42023_update_sites_extensions | InnoDB |
| j42023_updates | InnoDB |
| j42023_user_keys | InnoDB |
| j42023_user_mfa | InnoDB |
| j42023_user_notes | InnoDB |
| j42023_user_profiles | InnoDB |
| j42023_user_usergroup_map | InnoDB |
| j42023_usergroups | InnoDB |
| j42023_users | InnoDB |
| j42023_viewlevels | InnoDB |
| j42023_webauthn_credentials | InnoDB |
| j42023_weblinks | InnoDB |
| j42023_wf_profiles | InnoDB |
| j42023_workflow_associations | InnoDB |
| j42023_workflow_stages | InnoDB |
| j42023_workflow_transitions | InnoDB |
| j42023_workflows | InnoDB |
| redazione | InnoDB |
| scienziatoanchetu | InnoDB |
| scienziatoanchetuporto | InnoDB |
| scienziatoancheturume | InnoDB |
| spazioaperto | InnoDB |
| titoli | InnoDB |
| web | InnoDB |
+-------------------------------------------+--------+
110 rows in set (0.00 sec)

None is 'Memory' all are InnoDB

Thanks

I tried also to create a new article and it is not saved same error displayed

hmhm, that probably due to this code

It in use while indexing

Do you think i can comment out the row 625 ???

Or it needs a rework ?

Note: this installation is working on another host with same Percona Cluster but on joomla 3.9.25 with php php 7.3, while the new joomla is 4.2.9 with php 8.1.2

same configuration on both hosts

Well, you can try, no one can forbid you to do so :)
but it will be reset on next update.

Or it needs a rework ?

Currently I don't know how it can be done differently, to cover your case.
Maybe someone else will look in to it.

this installation is working on another host with same Percona Cluster but on joomla 3.9.25

In Joomla 3 this is dummy method

We could add a check to the toggleTables method if "MEMORY" is in the list of available engines returned by a "SHOW ENGINES" SQL statement. The check should be just after the check if we are on MySQL and should save the result in a static variable or a class variable so it is not checked every time. @Fedik what do you think?

That could work

Unfortunately the "SHOW ENGINES" SQL statement doesn't support a WHERE clause like the "SHOW COLUMNS" does, so we cannot check for a specific engine, we can only get them all and then check the result. We could also do a "SELECT * FROM INFORMATION_SCHEMA.ENGINES WHERE ENGINE = 'MEMORY'", but as far as I know we avoid queries to the information_schema since there might not be enough privileges in some database server environments.

For me would be better to add an option or a variable to TRUE or FALSE in the configuration of joomla or for the component itself

... so we cannot check for a specific engine

hmhm, or maybe can just wrap current query code in to try/cactah, and set "is supported" flag on first run/crash.

... so we cannot check for a specific engine

hmhm, or maybe can just wrap current query code in to try/cactah, and set "is supported" flag on first run/crash.

Could also be a way but then we should try to catch the right exception.

@claudiosoprano Question: How have you managed to install Joomla with a database server which doesn't support the "MEMORY" engine? I would expect the installation to fail here https://github.com/joomla/joomla-cms/blob/4.3-dev/installation/sql/mysql/extensions.sql#L607 . Or have you updated from 3.10? This would work because there is no change to the "MEMORY" engine on update, so there is no error on update.

I have made PR to detect MEMORY support in toggleTables() method #40373

Or have you updated from 3.10? This would work because there is no change to the "MEMORY" engine on update, so there is no error on update.

@richard67 I think it also possible to edit that file before installation. But not like this is recommended anyway :)

@Fedik This will fix the issue when running on a database which doesn't support the MEMORY engine. But that can only be the case on a site updated from 3.10. Installation of a new site will fail. @Hackwar What do you think? We could change the extensions.sql for mysql so it installs the table with the InnoDB engine and switching to MEMORY engine would be done in PHP only, and only when it's supported.

@Fedik I still would prefer to check with "SHOW ENGINES" because I'd not like to catch all kinds of exceptions. I could make a PR with that and additionally other changes for making new installations work on MySQL (or MariaDB) without MEMORY engine support.

I do not mind, if you think that will be better, we can close my PR anytime ;)

Yes, the correct solution would be to install as innodb, then after the SQL files are executed to change the engine to memory if supported and to extend the check in the toggle function to check that properly with the SHOW ENGINES command.

In J3 the toggle function isn't empty either. The class is extended by another, DB specific class. Since the changes in J4 have been reduced to nearly nothing, that distinction has been removed.

@Hackwar And what do you think about the fact that in extensions.sql we use the MEMORY storage engine for these 2 tables, so making a new installation on a MySQL (or MariaDB) which does not support that engine will fail, wile in the update SQL script where the finder stuff is touched, the table is not touched either, so if someone has set it to InnoDB it will remain like this until the indexer runs and then fail with the exception?

Yes, the correct solution would be to install as innodb, then after the SQL files are executed to change the engine to memory if supported and to extend the check in the toggle function to check that properly with the SHOW ENGINES command.

install as innodb, then ... change the engine to memory if supported

We updated from v3.x on a cloned server that used a single MYSQL server, then backupped with akeeba and restored with kickstart.php using the Percona XtraDB Cluster with no problems or errors

The problem is for example with mysql that

show engines;

will always answer that memory engine is supported because mysql itself use the MEMORY storage engine and it can't be disabled

https://forums.mysql.com/read.php?92,635909,635909#msg-635909

but Percona Xtradb Cluster (either using MariaDV or Mysql) will not support this engine, but mysql inside will always show

mysql> show engines;
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
| MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO |
| BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO |
| InnoDB | DEFAULT | Percona-XtraDB, Supports transactions, row-level locking, and foreign keys | YES | YES | YES |
| MyISAM | YES | MyISAM storage engine | NO | NO | NO |
| ARCHIVE | YES | Archive storage engine | NO | NO | NO |
| CSV | YES | CSV storage engine | NO | NO | NO |
| FEDERATED | NO | Federated MySQL storage engine | NULL | NULL | NULL |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
+--------------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)

and maybe also some other DBMS could answer in this way.

For this i asked for a variable configuration to set FALSE or TRUE to disable or enable the memory table engine

Claudio

So it seems we can't rely on the "SHOW ENGINES". That means we have to catch the exception like @Fedik 's PR #40373 does.

I strongly suggest to not add yet another manual option here. This has to be figured out automatically by Joomla as @Fedik did.

the query are two, i posted both in the Your text to link here...

Okay, I will reopen the PR, that fix for toggleTables,
however for installation it still need to implement something.

Okay, I will reopen the PR, that fix for toggleTables, however for installation it still need to implement something.

I think that can be done with a different PR.

@Hackwar Should we lave this issue open for the installation thing (which is buried in a comment below the initial post? Or shall we close it and make a new issue especially for the installation thing?

Closing as having a pull request. See #40373 .

Well the thing is that it is not even possible to disable the MEMORY engine on a MySQL or MariaDB because it is also used internally by the database server. The limitation comes from the replication of the Galera Cluster. See the first limitation listed on this page https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/

Currently replication works only with the InnoDB storage engine.

This explains why @claudiosoprano could install Joomla on a single database without replication.

All right @richard67, it is a limitation of Galera Cluster replication, mysql and mariadb support it, this is because SHOW ENGINES; command shows storage engine memory is supported but then it will not work on the Cluster, while on a single server all works like a charms, but with the patch for the PR it is working now.

Thanks anyway for the patch, i suppose it will be useful for others DBMS that don't use MEMORY storage engine.

The proposed fix is not enough.

The ALTER TABLE instruction on Galera clusters does not fail if the table is empty (as it is on a new installation), it only fails if the table contains at least a record. If the ALTER TABLE succeeds, MySQL returns an error at the first insert into the table. The detection logic should be improved.