Inconsistent persistence of database context across chats

[boyankostov]

When switching between multiple databases

• The active database context (DB2) from a newer exploration persists across older chats.
• Going back to a previous chat (using DB1) and trying to render results reuses DB2's context and generates an error

Steps to recreate:

1. Add at least 2 databases
2. Make an exploration with DB1, then click on Show results to make sure results are rendered in the table
3. Make an exploration with DB2, then click on Show results to make sure results are rendered in the table
4. Go back to the DB1 chat and try to click on Show results again.
5. You should see an error similar to the one below if the two databases don't have those matching tables.

[vdsabev]

What do you think we should do in this case? Persist the database / API key / model per chat? Or only the database? For the API key and model it makes more sense to be global, as you might want to switch models mid-chat for better results. There might be some value in switching databases mid-conversation but it seems more confusing than it's worth.

Also, what happens to existing chats if you delete a database that's in that chat? Can you no longer chat / run queries against it? Select a new database?

So what should the UI look like? You select the database before you send the first chat message and it's shown at the top next to the title, while the API key / model could be in the bottom left sidebar above the Settings. Or keep the API key and model in the textbox? I'm actually not sure they fit that well in the textbox, and sidebar might be better.

What do you think?

[boyankostov]

To me it makes the most sense to persist all chat settings. Even if not all, then at least the database. I would even go further and suggest that the database should become read-only once the chat has started.

For existing chats that no longer have a database maybe we could disable the Show results button (easy) or cache the data so that those buttons could work, of course only for the existing queries in the chat and for that snapshot in time of the database (harder). I'm biased towards the easy one atm though.

I think their current location is contextual enough but having the database there might be too much - Dropdowns are not that scalable horizontally especially when you resize the window. So if we remove the db from the message area and keep the rest that would be an easy fix. It makes more sense to keep them there because they are directly connected to the message you're writing. I would expand that with logging a timestamp somewhere in the chat that the model has been changed and the following query is using this or that model. But timestamps are probably another feature request.

[vdsabev]

We could store the model for each message and show it on hover - example from https://t3.chat:

[vdsabev]

Another consideration is - right now we don't have UI to edit database settings. Sometimes you may have to change the password or move the host for some reason, which means delete the old database and create a new one. So if we disallowed changing the database mid-conversation, you would have to start a new chat, and prompt the AI to generate that query again.

I can see the use case for persisting the database / API key ID per chat, but not allowing you to ever change it can lead to other problems - solvable for sure, but problems nonetheless.

[vdsabev]

I've added the model string to each message in ded5bfa so it'll now show under a response when you hover it.

On the issue of persisting database and API key IDs per chat - I need to think some more about that.