DUMP_ON_RESTART is ignored on create

[vladikk007]

I'm using docker volume to persist DB data. After container deletion and create again, it apply dump.sql so it restore DB even in cse DUMP_ON_RESTART is set to false. Could you please fix it? Thanks

[cdesiles]

Hi!
thank you for reaching us.
This tool has been designed for short term tests, therefore persistence has never been required nor wanted for the our users until now.

For my own understanding of your use case, what is your testing case requiring a persistence database?

DUMP_ON_RESTART is meant to container restart only, it is used here:

prestashop-flashlight/assets/run.sh

Lines 175 to 192 in 68877bb

	# Restoring MySQL dumps
	if [ ! -f $DUMP_LOCK ] || [ "$DUMP_ON_RESTART" = "true" ]; then
	echo "* Restoring MySQL dump..."
	[ ! -f "/dump.sql" ] && echo "Error: missing dump. Exiting" && exit 5
	if [ "$DRY_RUN" = "true" ]; then
	echo "(skipped)";
	else
	mysql -u "$MYSQL_USER" --host="$MYSQL_HOST" --password="$MYSQL_PASSWORD" "$MYSQL_DATABASE" < /dump.sql
	fi
	echo "* MySQL dump restored!"
	if [ -n "$MYSQL_EXTRA_DUMP" ]; then
	echo "* Restoring MySQL EXTRA dump(s)..."
	mysql -u "$MYSQL_USER" --host="$MYSQL_HOST" --password="$MYSQL_PASSWORD" "$MYSQL_DATABASE" < "$MYSQL_EXTRA_DUMP"
	fi
	touch $DUMP_LOCK
	else
	echo "* Dump already performed (see DUMP_ON_RESTART)"
	fi

This is why if you delete and start the container the lockfile would be void and the dump would occur again.

However if you want to prevent this code to even dump anything, you shall file a new PR introducing this new behavior.

I would suggest DUMP_ENABLED as a variable to manage this, defaulting to "true". And when set to false all the block L176 would be disabled, printing a message to the user "Dump has been disabled (see DUMP_ENABLED)".

If you have any question do not hesitate to ask,
Best,