-
-
Notifications
You must be signed in to change notification settings - Fork 835
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
flarum install should never nuke an existing DB #4018
Comments
Proposed resolution: if any of the tables already exists, |
Under normal circumstances, and from what I've seen when trying to run install on an existing database, is that Flarum actually errors with the fact that the settings table already exists. Is it possible this "nuking" is due to something on your end or in your hosting environment? |
I encountered similar issues when attempting to install Flarum on an existing DB:
This behavior suggests the issue is likely with Flarum's installation process rather than a specific hosting environment. I tested this on Linux PopOS VM with |
Ok I can confirm this. The logic is contained in the @flarum/core I don't think this is a wise solution, do we want to remove these for v2? |
we shouldn't modify the install dumps, instead we need to add a check before installFromSchema is executed in the same conditional statement. if (! $migrator->repositoryExists() && ! $migrator->installFromSchema($this->path, $this->driver)) {
$migrator->getRepository()->createRepository();
}
|
Current Behavior
It is obviously not acceptable for
flarum install
to drop entire database tables, such as the user tables, if they exist.Steps to Reproduce
php flarum install
on an existing DB.Expected Behavior
flarum install
exercises restraint if data already exists in the database, instead of wantonly deleting everything.Screenshots
No response
Environment
Whatever
Output of
php flarum info
No response
Possible Solution
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: