Refresh Schema Option In Query Builder Warning Popup

Have been planning to request this for a while now.
When getting a warning saying a particular column does not exist in the query builder, it usually because when we add a new column in DB outside of Wappler, schema for the table does not update.

Another case when this happens is when switching between targets. We usually have a staging remote target & a development target. Both share the same DB.
So if I am working on development and schema is all updated, if I have to just view an existing query when on staging target, I can not even open the builder UI without having to go into Wappler DB manager, locate the table and refresh schema.


Having an option to refresh schema for the table with this warning, would be a great addition and save a lot of time.


1 Like

@patrick Bump.
This is really annoying.


Related: DB Schema corruption and breaking server actions

Perhaps a fundamental better way of keeping this file up to date would be a better fix for many issues: DB Schema corruption and breaking server actions

Another bump.


New options added in DB manager, but this one is still required.


This actually will be solved for remote targets by disabling editing capabilities of server action when remote target is selected.

Editing should be allowed only on local development target. We can also add there a refresh schema button as well, but on local targets the schema is usually up to date.

One of the reasons why we haven’t gone back to using Wappler’s new resource manager and DB manager stuff. Weird restrictions, which make sense for average users, but should be a user-defined setting and not forced.

You are assuming that Wappler’s DB manager is used. Which we do not use.

That’s mean that this issue will be solve too by disabling editing capabilities of the server action when remote target is selected?

If I understand well if target is remote all Database Actions will be locked or the whole Server Action API?

That’s right, changing the database schema outside Wappler the changes are not up to date.
Personally I don’t use Wappler DB Manager and on every change in db I have to Refresh Database Schema manually.

But why would you like to edit directly an already published to live server, server connect action?
You always want to make first changes in a local development target, test if it is all fine then publish all the changes in a secure versioned way.

By just randomly edit directly your live server actions you are risking fully breaking your live site as you haven’t done any tests yet.

This is by the way not related to Database Manager - it is a controlled way of publishing from development to live sites.

Saving a file does not actually upload it to production - when using Docker.
When I used to use Wappler’s deployment method, I would just make changes while being on production target sometimes - for a quick fix. Having to change target just to do that is a hassle.

Right now I use Git based deployment - via Caprover - on almost all dev and prod applications, so I don’t even have a prod target. I read about some release-tag-Git support in resource manager, but never got around to testing it, since Wappler did not support multi-app deployment on same server that time. And now I am very comfortable using Caprover, since I don’t have to worry about dockerfile, resources, taregts or SSH keys on Wappler. Resource creation and management was not very reliable, but haven’t used it in quite a while, so can’t say about the current state with all the updates.

On a side note:
The idea of multiple targets only makes the development more confusing. It was a great thing to have when I started with Wappler… but over the years, I have realised that Git based deployment with the help of ENV variables is a way better approach to move things to production - specially when working with a team.
Target specific values changes in Wappler is not very reliable. Maybe it made/makes sense for PHP model, but for NodeJS, ENV & Git is so much better.

2 posts were split to a new topic: Git as target publishing