User quality of life improvements

[prrao87]

I'm listing some user inconveniences here to take a look at whenever possible (some of these might be related to the upcoming electron app).

• [x] Can’t rerun an existing query in the same cell by pressing Shift + Enter (user can rerun the existing query cell by mouse-clicking “Run”, but it would be nice to not have to involve mouse-clicks). It seems like the keyboard-only approach to running queries (Shift + Enter) always tries to run the topmost cell, when ideally, it would run the current cell that the user is on.
• [x] Cannot save commonly run queries for next session - it would be better to address this at the front end rather than the DB itself, as in many cases the front end might be accessed read-only by users who aren't doing the data engineering and managing the database itself.
• [x] If the local database changes, the Docker container must be restarted to see the changes in the UI. This isn’t immediately obvious to a new user as they may think they've done something wrong, and it’s also not convenient because they have to stop/restart the container (maybe this can this be addressed better with the standalone application?). See https://docs.kuzudb.com/concurrency/
• [x] Dynamically update graph using force-directed layout, see #85
• [x] Graph explore feature, see #6
• [ ] Standalone explorer app, see #8

[mewim]

1 is a bug. I fixed it in #70. 2 can be addressed with a persistent layer. Similar to #68, we should first discuss where to persist the history (and the style information). @semihsalihoglu-uw suggested that writing to the Kùzu database itself is not a good idea. Should we create a separate SQLite3 database or JSON files under the same directory? Another option is to provide a way to dump the session as a reloadable file (similar to what Jupyter notebook does) so that the user can open it later. Let's discuss some time regarding what to do.

3. Theoretically docker volume should be able to sync the data in real time. Maybe this has something to do with that some data is buffered in memory and the database is not aware of the changes. Maybe we can provide a database command for refreshing.

[mewim]

Update: 2 is addressed by #81

[prrao87]

I've compiled the existing UX enhancement issues in this PR and will pin this as it can be used to track our progress. Thanks!

[mewim]

I have implemented the button to reset the database connection in settings.

[prrao87]

@mewim I think the word "Reset" can mean different things to different people - some might interpret it as the graph itself being reset, i.e., their values erased or something like that. Could we say "Refresh connection" instead? And the message next to it would be "Kùzu connection has been refreshed."

Also, doesn't it make more sense to have this important button on the top ribbon, next to the settings and schema tabs? Putting it inside the settings table buries it underneath, and takes more clicks to do something as important as this.

[mewim]

I think the word "Reset" can mean different things to different people - some might interpret it as the graph itself being reset, i.e., their values erased or something like that. Could we say "Refresh connection" instead? And the message next to it would be "Kùzu connection has been refreshed."

1. I can change it to refresh.
2. I think it might not be a good idea to move it to top. First, the top bar is a navigation bar instead of action bar. Each button/link is for toggling a UI component instead of directly performing an action. Second, this button is designed for a specific use case. I do not think it is important for all users. It might confuse the user as they might not understand when this button needs to be clicked. Third, this button only works when no active query is running. I think it might be tempting to click on this button during a long running query if it is on the top bar.

[prrao87]

Hmmm, good points. I can see how it would be tempting to click the button too many times when the query is still running. Let's keep it underneath the visualization settings then.

[khakimov]

If the local database changes, the Docker container must be restarted to see the changes in the UI. This isn’t immediately obvious to a new user as they may think they've done something wrong, and it’s also not convenient because they have to stop/restart the container (maybe this can this be addressed better with the standalone application?).

that was my personal battle after I setup kuzu and was playing with explorer linked to ./db directory. I skimmed documentation about concurrency, maybe this issue due to this:

The reason for this limitation is that if a connection conn1 from db1 makes a write operation, say deleting some node record, then thedb1 object is able to ensure that any cached data in db1 is refreshed and is accurate. However, it cannot notify other Database objects that may exist about the change. So in our example, db2’s cache would no longer represent the true state of the data on disk that was cached. This can lead to problems if connections from db2 try to run queries after db1’s modification. Therefore, Kùzu will not allow multiple Database objects to be created unless they are all READ_ONLY.

[prrao87]

@khakimov, yes, we specifically added a documentation page about concurrency and connections recently to explain this better. Hopefully the FAQs at the bottom of the page help users like yourself in understanding this better, and in working around it. As a best practice, it's recommended to only open Kùzu Explorer after a write process has finished updating the graph. If we find a better solution (or if you know of any other DB that has solved this issue), the workflow guidelines can be updated accordingly 👍🏽 .

[khakimov]

@prrao87 docker recently (last year) released watch feature [1], at least for auto-restarting docker depending on .lock? I will look into this. Another (ugly?) option to use inotify... :-/

[1] https://docs.docker.com/compose/file-watch/

[prrao87]

Closing this as the only issue that's possible to resolve in this is #8.