Thanks @rcwestlake — not able to reproduce this one. Still happening?

I'm experiencing the same thing with version 2.38.1 on Arc Browser, Safari, and Chrome. The dropdown menu that's typically on the right side of the item label is no where to be found.

I can also confirm this issue.
supabase/studio:20230921-d657f29

I don't see any related error in console :)

Also, whenever do you make a query, close the window and reopen SQL editor all created queries are gone and only the defaults remain.

any update on this I'm using supabase-cli version 1.110.1 and I can't even make sql statements in the editor very bizarre.

This is still happening on 1.113.3. Can we get an update on a possible fix?

confirm bug with these version:
supabase/studio:20231030-9abc686
supabase/studio:20231123-64a766a
supabase/studio:20231127-81e146f

method PUT not allowed on endpoint: api/projects/default/content

but when i used older image:
supabase/studio:20221214-4eecc99

its works and its used method PATCH

Any updates on this?

had the same issue on web just now, logging out and back in fixed that for me

had the same issue on web just now, logging out and back in fixed that for me

Same here. Dropdown was showing but Rename query action was not in it. Logging out and back in fixed it.

can confirm issue still exist on studio. i'm on 1.131.4

Hi folks, thanks for reporting back on this. We are looking into this now and will triage it to the frontend team!

Hi all — apologies for the delay on this one.

Quick update:
For hosted (supabase.com) projects: This was a bug that should be resolved now.

For local and self-hosted projects, there currently isn't a way to save queries to your project. Hence we just give you one SQL workspace to work from, without the concept of individual snippets. We recognize that this isn't ideal and are thinking of solutions to allow you to save snippets here like you do on supabase.com.

We appreciate the reports and hope to get a solution out soon.

@saltcod @encima would you be able to just store the queries into a text file of some kind into the supabase folder that's created and then just read from it? Wouldn't need to be anything fancy =)

@saltcod @encima would you be able to just store the queries into a text file of some kind into the supabase folder that's created and then just read from it? Wouldn't need to be anything fancy =)

Hi @whoiscarlo,

I like your creativity. Unfortunately, it is not so simple as it is harder to maintain and the functionality to do that is quite different from the platform. We are discussing this internally and will update as soon as there is one!

For local and self-hosted projects, there currently isn't a way to save queries to your project. Hence we just give you one SQL workspace to work from, without the concept of individual snippets. We recognize that this isn't ideal and are thinking of solutions to allow you to save snippets here like you do on supabase.com.

Well - how about just some simple local-storage fallback at least? Wouldn't be some great solution but at least serve it's purpose quite well for now.
But loosing all written SQL just by maybe an accidential reload is quite annoying tbh.

how about just some simple local-storage fallback at least

We did consider this! More specifically using index DB - in the midst of exploring options

separately just FYI i'm gonna change the tag from bug to enhancement, since this isn't a bug 🙏

1 please

still same error :c

how about just some simple local-storage fallback at least

We did consider this! More specifically using index DB - in the midst of exploring options

separately just FYI i'm gonna change the tag from bug to enhancement, since this isn't a bug 🙏

Nice enhancement from non working to working

Bump.
Considering this could be quite the quick-win, any idea on when this might be fixed?
If someone could point me to the correct code, I would even consider making a PR for this myself.

It is still being considered how this can best be done, we will update here as soon as we have more info.

would you mind sharing the what's the complexity here? for me this seems quite straightforward.
also, just placing the script as string in localStorage would suffice temporarily.

This is very basic UX functionality, please fix this bug

Apologies for the silence here, it is being considered still. The problem of implementing a "quick fix" is that it needs to continue to be supported so, ideally, we want the self-hosted Studio to be as close to the hosted version as possible.

That said, we are very open to PRs so feel free @olee (the code is in the SQL editor code under the apps/studio folder)

confirm bug with the latest version:

image: supabase/studio:20240514-6f5cabd

I would absolutely love this feature!!

Since this feature is still not implemented, does anyone have a better workflow for local development? I am not an expert in databases and was wondering if I can also develop from local SQL files instead of using the SQL editor in the supabase studio? Losing all the written code has really caused some frustration.

Any updates on this?

Since this feature is still not implemented, does anyone have a better workflow for local development? I am not an expert in databases and was wondering if I can also develop from local SQL files instead of using the SQL editor in the supabase studio? Losing all the written code has really caused some frustration.

Yes, 100%! You can put code in your supabase folder and apply it through migrations.

Check out migrations for this.

Another option would be to apply sql files through psql

At the least could show the actual queries with the text clipped. As of now, it's just rows of 'Untitled query'

Since this feature is still not implemented, does anyone have a better workflow for local development? I am not an expert in databases and was wondering if I can also develop from local SQL files instead of using the SQL editor in the supabase studio? Losing all the written code has really caused some frustration.

Yes, 100%! You can put code in your supabase folder and apply it through migrations.

Check out migrations for this.

Another option would be to apply sql files through psql

This solution has been helpful. I have created a file structure to organize all my logic, making it much more readable. However, it remains somewhat messy due to the fact that it is pure SQL and not a backend framework. This becomes noticeable when you need to use global variables or when your logic becomes more complex, as it can reduce readability.
Is there perhaps a better linter for PostgreSQL that can visually represent the files in a more organized manner? Alternatively, is there a way to use a backend in front of the SQL code? The problem I face is that I do not want to host an additional backend and incur the associated costs. Supabase is free in the initial stages, which is why I am currently using it. I would really like to here some best practices. Maybe there is a source where I can do some more research. My architecture knowledge is very limited.

@nilsertle I have had a much better experience using Datagrip IDE. It has a full-fledged language server for Postgres, and makes the developer experience of working with Postgres SO much better. The caveat is that it is a paid service (although I get it free through my university).

There are also several open source projects that are in the works to implement a similar experience to that of Datagrip in other editors like Neovim and VSCode. The most notable being Supabase Community Postgres LSP. Once there is an open source full LSP for Postgres development will be a lot more manageable!

how about just some simple local-storage fallback at least

We did consider this! More specifically using index DB - in the midst of exploring options

separately just FYI i'm gonna change the tag from bug to enhancement, since this isn't a bug 🙏

With all due respect - but I do think that this is a bug, not an enhancement. The UI shows "Untitled query" when clicking "new query". Both the appearing of the untitled query in the menu, as well as the button 'new query' imply that:

1. Queries can be new, which doesn't make any sense if they cannot be saved.
2. Queries can be untitled, which implies that they can be titled as well. This requires saving, which is currently not possible.

I don't think it makes logical sense to label this as an enhancement. It is, derived from the above logic, a bug.

In two months time, this issue is 1 year old. Is there any progress or decisions?

The nudge to contribute is helpful, @encima, but it isn't very appealing to invest time when we don't know the internal decision(s) regarding this.

Agreed and we do apologise for this. The self-hosted functionality is a key reason for why I chose to work at Supabase and the work that is being done on the self-hosted side by the team is amazing. As an anxious person (aren't we all?), seeing a notification from this Issue strikes me with fear and sadness because I know you all want it solved and I also know how hard the @supabase/frontend team is working

Keeping these features in sync is tough and, when the self-hosted version does not have a management API, it becomes a real challenge. Personal opinion: I would like to see a dummy management API in the self-hosted version that could mimic some of the functionality.

Of course, as many people here have suggested alternative approaches, we do not want 3 different PRs opened with different approaches.

So..my suggestion is this:

• I organise a meeting with the Frontend team to discuss what could be seen as an acceptable implementation and post the notes from that meeting here
• I will create a branch with an attempt to start this implementation (sadly, the frontend is not written in Python in 2010 so it may suck)
• Those willing can then contribute to this branch so that we know effort is combined and the solution is not wasted
• If the frontend team agrees, we can aim to implement this (community led) before this issue is 1 year old and the team can then review it.

Thoughts and alternatives welcome!

@encima Thank you for the prompt response, and understandable that it makes invokes some feelings seeing a notification from this issue (first hand experience with that.. ). It's all good, just wanted to sharpen the situation with this issue and move it towards completion seeing the amount of people that run into this. First step in my head was changing the label back to 'bug' to increase urgency.

The approach you listed is very welcome, that'll probably move it towards completion rapidly.

It might also be a good idea to open an issue for implementing a dummy version of the management API and do a call for collaboration on that?

In any case, I'll keep my eyes on this issue and if help is needed with implementation I'll see if I can help.