Connecting to new, prod mysql8 db - connection timeout (Workbench connects perfectly)

I don’t really follow why you feel it’s not a bug? (Please don’t take that the wrong way). It certainly could be user error but otherwise…

Old projects > I can use dB with remotes.
New project > I can’t.

I’m certain the default dB has not been designed in such a way that you can’t connect and maintain remote connections.

I can see why you would see it as a bug, but to me, for a scalable app, I’m always going to set the DB connection separately. Whether or not one considers it a bug is irrelevant, it needs looking at :kissing_heart:

@George

I finally managed to connect to the remote MySql8 db this morning, with the default db.

What I found out was that if I create a docker target and select ‘none’ for the db then whatever I try to do - the default db just won’t connect, I get the above mentioned file missing errors and other errors.

If I select a DB as the target and then try to change the settings or both db.json files, I continue to get timeout errors regardless of what I try. It just fails.

Working Order:

  1. Create the Docker Remote WITH a MySql DB chosen in the target. Doesn’t really mater what credentials go in there - but I input the expected remote credentials.
  2. Once the target has been created I then go back to the target and THEN change the databsae settings to ‘None’.
  3. I then go and change both db.json files to match the remote db credentials. Now it works.
  4. But then there is the issue of applying all the DB Manager changes, for example if the original Docker DB was created with dummy data. I had to use an external service (workbench) to recreate the DB schema so that the stored db changes would be able to be applied (as it needed to drop those tables).

So, clearly either some files are missing when setting up without a db in target settings on creation, and if you leave the target for the default db - you cannot connect to a remote db without then removing that.

I’d say from a UX perspective, this isn’t great, and especially for any new to using Wappler this may be quite an uncomfortable experience - especially requiring them to edit the db.json files manually.

Anyway, it’s working so over to you guys for review/improvements. Feel free to unlist.

1 Like

The “flexibility” feature to Define & then modify Database connections from different access points, obviously, needs some logic refinement as to how Wappler processes what you intend to do.

Since defining a Target is Step One then there ought to be, I think, a SEPARATE clearly defined Check box or slider Off/On that stores immediately "Do you want this Target Setting “My Master Killer App database remote” to be the DEFAULT MASTER for this “Debugged Remote Killer App” Project?

The variables are defined in a separately dedicated file “target_master_default” that is always read first before any connections get written with each save & deploy/upload.

A Master Connections file for the project folder should be safely stored outside of the current updatable files for Connections. And in Target you can call it up and Modify it at any time – but when you see it in Edit mode it ought to be a rock-solid confirmation that so far this is the Master connection configuration saved & used.

OR something like this :face_with_monocle: ?