Allow database schema edits only on local development targets
I would like to ask the community if you like this feature and if it is useful for you?
For me personally, after this update, the Wappler database manager died. I had to go back to the old way of working with the database - phpmyadmin. This was due to the fact that this function slows down the work with the database via the Wappler incredibly (for me personally). I don't do development locally. For development, I have a separate server that exactly copies the production server environment. This allows you to immediately see how it will look and work in production during the development process. So now, in order to make any edits to the database via the Wappler, I need to switch the target to the local one each time, make changes, upload to the server, and then switch back to the remote target. It's long and uncomfortable. So I'm using phpmyadmin again. I'm not complaining, because there's nothing wrong, although it was quite convenient to work with the database directly through the Wappler. I just wanted to find out how others are doing, are there any people who are also uncomfortable working with this feature?
Intreagued, why long and uncomfortable. It's just a few clicks, select production target, hit upload changes, ,reselect dev target. Got to be easier than dropping into myphpadmin and manually changing both ( with potential risk of a mistake between copies)
Because at the initial development stage, there are a lot of database changes and they are made often. In this case, there is no production and you do not need to check the new database schema. But jumping between target a hundred times within an hour is inconvenient, slow, and sometimes there are unpleasant situations when you forget to switch back to a remote goal and develop locally, without understanding why the changes are not displayed on the site. You spend an extra minutes to figure it out again and realize that you forgot to change target.
As for changes to the database in working projects, the new feature gives absolutely no protection against errors (for me personally). When making changes in a working project, I always keep a separate file in which I mark all the changes. And after the development of the new functionality is completed, before deploying to production, I make very carefully all the changes to the database for production according to the records made. For me personally, this is the best method.
Therefore, I do not see any profit in the new function.
I wonder what this new feature gives you? What kind of protection and in what situations? What errors occurred when this function was not available?
We are currently indeed checking if the target is local and set to development and allow database edits only then. Maybe that's a bit too much, so we will indeed remove the local requirement.
In the next update we will allow remote database edits, as long as the target is set to development.
That's all done to protect users from accidentally editing their live/production targets and breaking the site. So you should always first test them on your development target and when you verify everything is working fine, then you can push to live/production target.
I am used to working with very strict restrictions on anything that is not a DEV system so it’s kind of in my DNA. So as long as it’s marked as dev I see no problem if it is local or remote.
Yeah I was wondering this, as well. I am struggling to replicate my development database structure in my staging environment. Somehow some changes are conflicting. So I just want to manually add some fields to some tables, But I get this message:
