Left tree collapses at random

[meglio]

Description

The database/tables tree get collapsed at will.

DBeaver Version

Version 24.1.5.202408181605

Operating System

macOS Sonoma 14.6.1

Database and driver

PostgreSQL, but it does not matter for this bug report.

Steps to reproduce

1. Expand the database/tables tree on the left.
2. Put your laptop to sleep for a minute.
3. Awake your laptop
4. The tree is collapsed

Additional context

No response

[ged-yuko]

1. Expand the database/tables tree on the left.

At this step database connection is being established and DBeaver reads information about the tables from the database.

2. Put your laptop to sleep for a minute.

At this step database connection is being broken, but the system switched to sleep mode, so DBeaver may not have time to react.

3. Awake your laptop

At this step the DBeaver also awakes and finally handles disconnect (the same as when you intentionally click "Disconnect" while the database is selected), so the database subtree contents cannot be manipulated with, so DBeaver collapses it.
Autoreconnect could have been initiated here, but only if the disconnection detected during normal DBeaver operation. But in this case it is a result of sleep preparation procedure, so then DBeaver just handles system's state change.

4. The tree is collapsed

@

[ged-yuko]

The reasons i described just prove the fact that the behavior observed is neither feature nor a bug. There is no will and no intention to collapse the tree for an operational database connection, and no randomness about it.

So what you want is apparently a new feature request: to not collapse the tree when the connection is being lost and/or closed. Or at least to optionally (because not any user wants it, otherwise you could have find a multitude of such a requests already, i believe) preserve the expansion state and restore it on reconnection. And maybe try to reconnect if there was a power state change event and resume-after-sleep detected in some way (i personally don't know any available for Java-based programs at the moment, because corresponding OS' APIs are not exposed by JVM). And also maybe have corresponsing settings on per-connection basis rather than globally (DBeaver already has global and per-connection preference profiles, so the last piece is already in place).

There is a whole plenty of scenarios and decisions to make while designing the approach to cover behaviour which looks for you so obvious and simple, but is a result of the whole software+hardware system combination, where DBeaver itself is the least influential.
I personally am of no authority on whether DBeaver's team is willing to dig into this, assuming they know it all better than me: how to handle UI events on disconnected entities while all the cached info is being invalidated, so should be dropped, and so on, and so forth. Also note that database is not the only problem here, because there is CloudBeaver on the table, where the whole workspace is being invalidated on disconnect, including scripts and other stuff, so it is much less obvious than you might think.

[meglio]

There is no will and no intention to collapse the tree for an operational database connection

But it does collapse, and it does make developer make extra clicks to expand it back. So this is a bug / a user experience issue.

because not any user wants it, otherwise you could have find a multitude of such a requests already, i believe

This type of assumption is always wrong: very few users have energy and time to go and report something or ask something in GitHub. Most of the users just have to do the annothying thing over and over and get used to it, and never report on the problem. Because reporting takes effort. Look how much time I already spent just trying to convince the developers ot DBeaver that is actually is a user experience issue. Few people willing to spend that much time.

There is a whole plenty of scenarios

Look, there is standard everyday scenario: I work, I close the laptop or log out of user account and go have a coffe, and then get back with the intention to continue my work, but now I have to make 5 extra clicks. Every other IDE and application is the way I left them, but DBeaver makes me do extra clicks every single time and it make me pull my hair out. WHY? It is absurd to make me do it. All I did just close the laptop to go have a coffee? What are you talking about - what plenty of scenarios. Can we not turn to common sense here.

[ged-yuko]

But it does collapse, and it does make developer make extra clicks to expand it back. So this is a bug / a user experience issue.

It is remarkable, how you ignored the point: no, it doesn't collapse for operational database connection.
Networks connections break, it happens. This is just one of these scenarios, not special. Then there is a choice: show you nav items which are not operable and dont reflect the state of database anymore, or hide them. DBeaver does the second. Maybe this concrete scenario with system sleep state might be handled in a special way, if it is possible, but by default it is not a special case and the application works not incorrectly. Not expected for you personally - maybe. But it doesn't break workflow and doesn't throw a ton of error messages on unexpected disconnection.

Also to me this complaint looks like: the door to my household closes each time on its own, and it makes every neighboor to open it back while passing, which is especially uncomfortable when one has a hands full of bags, so this is a bug.
We both know, its hilarious. There is logic behind how things work sometimes. Even when it is not always comfortable.

This type of assumption is always wrong: very few users have energy and time to go and report something or ask something in GitHub. Most of the users just have to do the annothying thing over and over and get used to it, and never report on the problem. Because reporting takes effort. Look how much time I already spent just trying to convince the developers ot DBeaver that is actually is a user experience issue. Few people willing to spend that much time.

Oh, your opinion about my assumptions is wrong. I do agree that the behavior observed deserve further considerations and attention. Although it is not pointless as it is, to have it improved according to your proposal might make user experience better. But, from the point of the product, the last is a subject for cognitive research and features prioritizing. There is a buch of real "not working as designed" problems. This is simply not one of them.
It would be nice if our discussion would trigger DBeaver's management to redesign something. So my pleasure in clarifying technicalities for you.
It's just I am completely opposed to the approach "every thing which hurts me is a bug" and even more opposed to "willful misbehavior". Especially when I know the background reasons, how computer system works, and I can see the code here in github.

Every other IDE and application is the way I left them,

Every other IDE and application i ever used to work with databases (and any other related with network connections) follows one of two approachs on disconnect (no matter what the reason, network flaw or system power state change):

• it either ignores the fact at the moment of UI activation, and then fails on an attempt to perform a certain operation with "accidentally" invalidated entity, aborting the operation completely and forcing me to manually reestablish all the connection states (manually press "Connect" and "Disconnect", and all these stuff, depending on the particular app);
• or it detects the connection disrupture and automatically tries to reestablish the session (which would still be invalidated from time to time) and then often throws disconnection error message at me.

DBeaver already does better than both: it doesn't throw unwanted error messages at me, until things go really bad, and it automatically reconnects when it is possible. Maybe not always when expected, but still successfully than many others.

Just for example:

• SSH client app? - "you've disconnected!" at any random moment of time - go restart the session manually, sometimes the whole app, if there were tunnels, then go restart forwarded connections as well.
• RDP connection? - running out of reconnection attemps - "you've disconnected!" - go restart the session manually, if the server-side session is alive - bless you, other way restart all the apps on the server manually as well.
• VSCode terminals? - just closes terminal tabs dropping their state, reconnection gives you new clean tab.
• Visual Studio Server management toolbox? - stucks, then "nah, something is wrong" - go press disconnect-connect manually, disconnection collappses the server node, expansion state drops even if it reconnects on its own for any reason.
• Remote system management console? - just go forcibly close ALL the connections and reestablish them from terminal with admin priveledges manually, other way it would just stuck until timeout, and no guarantees to reconnect successfully on its own.
• MSSqlMS? - ignores connection state, then stucks to "app doesn't respond" on reconnection attempts triggered by UI operation, blocked UI parts not operational till explicit reconnection, if schema changed - go press refresh manually, otherwise invalidated parts not operational and produce error messages.
• Oracle SQL Developer? - there is s special extension to keep connections alive! (the other way they terminated on timeout even when everything is OK) - which won't help preventing connection from being dropped on real connectivity outage, invalidated UI parts not operational till explicit reconnection and/or manual refresh.

That's what I am talking about: other user's experiens may be drastically different than yours. I cannot judge you for your "every other IDE", you cannot blame me for mine. There is always bigger picture.

From your perspective it is "just closed the lid", from DBeaver's perspective it is "the whole world around accidentally turned off." So you want it to not notice the whole world disappearance? Don't log out (just lock the desktop session) and don't change the system's power state to anything but "turned on." You wouldn't expect on-air TV show to pause when you turned the TV off, would you? Network connections are exactly like that. DBeaver does pretty good job if you didn't notice that with full understanding yet.

[meglio]

Come on, where is your enginneering and where is your ambition to make things happen!

It is already taking much longer to discuss it than to do some R&D in the code and actually come up with a good way to fix it. You spent all that time and effort to make a list of how other software behaves when disconnected, just to defend the existing weird behaviour of DBeaver that annoys the developer who puts their laptop to sleep and then returns back to work.

This approach I would name "using technology as an excuse instead of using it as a means to actually make things happen".

Can you maybe leave the tree open marked as "outdated" and do all the reconnection and schema re-fetching in the first seconds while I'm looking at the tree and getting back into the context of my work? Chances are, DBeaver will be done rescanning and updating the tree while I'm looking at it or navigating it or deciding what I will do next. -- this being just one possible solution that comes to ones mind immediately as the most obvious.

If it happens so that I open some entity (e.g. a table), show a spinner and prioritize refetching its schema, that's all, very simple, won't that work?

There are miriads of ways to leave the tree open. What are the chances that while I had been having a lunch my database schema changed so much that the whole tree would stop making any sense? Seriously, the chances are... close to zero.

What if instead of spending another half an hour on writing another opus in Discussions defending the existing behaviour and explaining how it is impossible or very difficult to fix it, the half an hour is instead spent on actually thinking through a solution and doing little R&D in the code.

P.S. Hm, I'm explaining all this and kind of failing to believe that you can't put yourself into the shoes of a DBeaver user and imagine how annoying it is for him to go for a coffee and return back and find out that the IDE decided to close the schema tree, and now he hasto make 5 clicks. And then it happens every single time. It seems so obvious that it does not even deserve a discussion. Just fix it and forget about it, no? You want an epic half-year-long thread that will anyway eventually lead to a fix, just after another half a year of annoything database developers with weird behaviour. I don't get it. The barriers of "getting a manager approval" is in the heads of developers. Just fix it! Everyone will get happier and thankful, including the team mates. P.P.S. And fire the manager who requires a lifelong discussion and endless meetings to gain the green light to fix obvious annoying UI quirks ;)

[ged-yuko]

You seem don't get it: I know that Java applications (of which DBeaver is a particular case) don't have adequate cross-platform capabilities to detect power state change, because there are no such means in both Java and Eclipse platform (which DBeaver is based on). I don't need to R&D it. This is a fact, period. I also know how it still could be implemented from scratch. But there is already a ton of existing code and features in DBeaver to support which doesn't work as expected. There is nothing to defend against, because I also agreed that the matter being discussed provides a valid feature request.

[swordfish444]

@ged-yuko @meglio Yes this is my biggest gripe about DBeaver, the fact the tables in the left do not automatically open when you are viewing a table in the right is unbelievably frustrating. I have to click 7 times to get to the tables list when i want to explore the other tables. Just like when you are in an IDE and you're viewing a file, the FS tree expands the files and shows you the selected file in the left, I would expect the database tree to do the exact same thing.

[ged-yuko]

@swordfish444 please try to use Link with editor command of the navigator, when the table editor is opened:

Navigator should automatically expand till the corresponding table node.