On every installation I've had to manually hack the system to use Aria instead of MYISAM, and then it reverts my changes whenever I install updates. Now I have a bunch of unencrypted tables which is frankly unacceptable. For the love of all that is holy, either add Aria to the list of supported storage engines, or stop reverting custom changes!

community.limesurvey.org/feature-request/
or
community.limesurvey.org/bug-tracker/

Else : www.limesurvey.org/manual/How_to_contribute_new_features

supernovus wrote:

For the love of all that is holy, either add Aria to the list of supported storage engines, or stop reverting custom changes!
 

How should the update system recognize your modifications and preserve them? As already suggested you can open a feature request for adding suport for aria or a way to preserve modifications Perhaps you can add a with words about your motivation to use ARIA..
For all others interested in Aria take a look at mariadb.com/kb/en/aria-faq/

I may look at implementing it myself and submitting a patch/pull-request, as I figure if I'm the only one who's mentioned it, it's not a high enough priority to divert official developer time on.

I have no problem with any changes made to actual controller code being reverted, as that's the only way an updater can work properly. Any of the changes I made on that side of things should only have been required during the initial installation/setup when the config.php is created. I am wondering under what circumstances the config.php file itself should be being modified after installation, and if this whole thing was simply something I missed somewhere during the hectic process of expanding from 4 sites to 13 sites. As double checking, only just over half of the installations seem to have the wrong mysqlEngine setting, and since changing it back, it's persisted in the last few ComfortUpdate runs. So whether it really was reverted or was just missed during setup I don't know at this point.

As for my reasoning for Aria, it's mostly because MyISAM does not support table-level encryption which is a requirement from several government agencies we do surveys for. Not to mention since switching to the "crash-resistant" Aria engine we haven't had a single corrupt table requiring running a manual repair process, which is a huge bonus!

I tried to use InnoDB during the installation as it also supports encryption, but the installer had a big warning about how using InnoDB with LimeSurvey was more restrictive and not as well supported. So using Aria which is designed to be a drop-in replacement for MyISAM was the best option.

Honestly I think in the long term we may look at switching to PostgreSQL for most of our DBs which would make this whole thing a rather moot point.

Anyway thanks for the links and info. Cheers!

supernovus wrote:

I may look at implementing it myself and submitting a patch/pull-request, as I figure if I'm the only one who's mentioned it, it's not a high enough priority to divert official developer time on. 

Clearly : start by a feature request, some other people can be interested

supernovus wrote:

As for my reasoning for Aria, it's mostly because MyISAM does not support table-level encryption which is a requirement from several government agencies we do surveys for. Not to mention since switching to the "crash-resistant" Aria engine we haven't had a single corrupt table requiring running a manual repair process, which is a huge bonus!

I think LimeSurvey GMBH use mariadb for hosting, and they have goverment for client. I think they can be interested.

supernovus wrote:

Honestly I think in the long term we may look at switching to PostgreSQL for most of our DBs which would make this whole thing a rather moot point. 

PG have encryption solution ?

EDIT : Moved to Future Feature