#41 - has this been tested on D10? Any plan of releasing this patch to 9.0? I am currently using the module in D10 and the key_value table is 3GB+ which is affecting the overall performance of the site.
I've added a new feature which is the ability of changing the output file location
- 🇫🇷France izus
We just need to let user choose to keep storing in database or in files (depending on their needs and possibilities), so an option on that would be great
- 🇨🇭Switzerland berdir Switzerland
This is only about where to store the extracted text from files for indexing. This is a system/admin level, global decision, it can not be per user.
- 🇫🇷France izus
yes of course, this is what i meant, have an option to let the admin decide if they want to store on database (as currently) or in the file system (as dne by the patch)
- 🇺🇸United States lhridley
@rahaf-albawab Please provide an interdiff of the patch on #57.
- Merge request !35Don't store full extracted file content data in the database → (Open) created by berdir
- 🇨🇭Switzerland berdir Switzerland
This was a rough one to reroll, I'm not sure against which branches the rerolls exactly where, but even the last had several complicated conflicts due to DI changes for me on 9.0.x. Updated the issue fork and created a MR for it, didn't test this yet at all.
Re #64:
> yes of course, this is what i meant, have an option to let the admin decide if they want to store on database (as currently) or in the file system (as done by the patch)I don't get this. The patch introduces configuration and a UI to configure the desired cache implementation.
I noticed that there are now 10.0.x tags, but the branch is still 9.0.x. @ixus, note that you do _not_ need to create new major versions just to update the Drupal core requirement. That only needs a minor update.
- 🇫🇷France mably
Tested successfully on Drupal 11.0.10 / PHP 8.3 / Solr 8.11.3.
Nice work everybody!