Great video Jon. I just wish there was a better way to organize these functions. Seeing a flat list of functions in the dashboard is what deters me from using them more.
While there are obvious performance benefits (and even security ones, especially when accessing your DB from multiple sources) I think it's undeniable the DX for this is much, much worse vs handling this on your server. Both in writing, but also in debugging and maintaining. Wish there could be some progress made on this front.
I do agree the DX is much easier when doing this on the application side (more familiar and more code-like, as opposed to SQL). What are all the options for handling this? We have 1 - application side flow (doing repeated sql calls to db and handling responses) 2 - postgres function (this video) do ORMS like prisma just do it like option 1?
Using Prisma for those cases is a good solution, you can create nested writes or use the $transaction api to write your array of transactions. They have an example in /docs/orm/prisma-client/queries/transactions for a similar example of a money transaction where they withdraw and deposit in the same transaction and rollback if it encounters an error.
Eso es usar el paradigma "procedural" o "funcional", en una base de datos. Yo lo hago todo el tiempo, literalmente manejo todo desde la base de datos, en el frontend solo hay; labels, layouts, textboxs y botones (pocos, porque no confío en los usuarios/humanos). El resto... Desde la vase de datos ❤ (Toma en cuenta que Postgres es una de las bases de datos más pulidas que existen) Entonces... Cuando le haces ing. Inversa a mi App/ programa, solo te encuentras con un cascarón vacío. Y de ahí a romper/hackear el Api y el server... Es un trabajo que bo cualquiera podría llegar a lograr (Sobre todo, si manejaste bien las Funciones y sus argumentos, RLS, Gatillos, Roles, Permisos, etc.) Aunque no lo creas... Con Appinventor + Supabase; e creado "MVP's" más, eficientes, eficaces y seguros que el producto final de un equipo de "programadores", con 160k de usuarios conectados simultáneamente, con más de 40k de transacciones por segundo (con datos ultra confidenciales). [Sin usar autenticación, JWTs, Oauth, etc]. Solo porque se manejarme con la base de datos.
Struggling to find the documentation around the `client.query` API the way transactions are shown in early part of this video. Is that API documented on the Supabase docs site?
Great video. Is there any way to manage these functions via your git repo and have them update on push or merge to master? Now that would make me use them much more and maybe some day will be possible if not already
It depends on your project setup, but at the end of the day these functions are written in plain SQL in files that live in your project repo, possibly next to all your other SQL scripts. You can use any migration tool you’re familiar with to add them to Supabase. Just make sure to drop the previous version of any function you’re updating before applying the new ones.
yes, you should be using supabase migrations framework which allows you to easily keep local/staging/prod up to date with your functions and schema changes.
Hello, how are you? I created a function and I'm calling it using RPC: let { data, error } = await supabase.rpc('get_products_for_establishment', { establishment_id: 1, }); if (error) console.error(error); else console.log(data); But I'm encountering this error: Argument of type 'string' is not assignable to parameter of type 'never'.
Thanks Jon. How does putting it inside a function make it into an atomic transaction? What happens if that first insert fails how does it know to roll back?
This is a great question. I'm not convinced that just putting statements in a function "conveniently" wraps them in a transaction. My understanding was that the function runs within the transactional context of whatever is executing the function. Perhaps supabase RPC begins and commits the transaction? It's important because if the intention of the function is to encapsulate a transaction perhaps it's better to do it explicitly in the function body.
@@michaeldausmann6066from the postgres docs: PostgreSQL actually treats every SQL statement as being executed within a transaction. If you do not issue a BEGIN command, then each individual statement has an implicit BEGIN and (if successful) COMMIT wrapped around it. A group of statements surrounded by BEGIN and COMMIT is sometimes called a transaction block. so triggering the function executes it within a transaction. It's easy enough to try it out to verify.
I find it way to complicated to create functions and it is such a bad experience. Would be nice to have solution inside the application code. Since those functions also hold valuable information about the logic and what the app actually does.
A bigger issue with the app-side transaction management approach than coding mistakes IMO is there's no guarantee your code completes. Worst case the VM loses power unexpectedly. Although the recent crop of durable execution platforms such as Golem Cloud could mitigate that.
Postgre es mi sistema operativo favorito 😂 ¿Sabías que puedes jugar Doom en Postgre? Y Supabase es palabra mayor ❤ porque solo apareció, de la nada! Y todo aquel que buscaba oro en encontró Adamantium y Vibranium en un solo lugar.
Great video Jon. I just wish there was a better way to organize these functions. Seeing a flat list of functions in the dashboard is what deters me from using them more.
True
So true!
yeah just give us folders and it is 10x better
this
THIS! Yes please organize better
Jon is back! He says Dahtah funny! But he sure knows his transactions.
While there are obvious performance benefits (and even security ones, especially when accessing your DB from multiple sources) I think it's undeniable the DX for this is much, much worse vs handling this on your server. Both in writing, but also in debugging and maintaining. Wish there could be some progress made on this front.
I do agree the DX is much easier when doing this on the application side (more familiar and more code-like, as opposed to SQL). What are all the options for handling this?
We have
1 - application side flow (doing repeated sql calls to db and handling responses)
2 - postgres function (this video)
do ORMS like prisma just do it like option 1?
introducing postgres react procedures... with redux
Bleh i almost throw up when i need to manage my transaction logic from supabase dashboard instead of codebase :c
Using Prisma for those cases is a good solution, you can create nested writes or use the $transaction api to write your array of transactions. They have an example in /docs/orm/prisma-client/queries/transactions for a similar example of a money transaction where they withdraw and deposit in the same transaction and rollback if it encounters an error.
We need a way to sync local Postgres functions with Supabase using the Supabase CLI, it's much better to have them in code locally.
that's what migrations are for...
Calling a db functions inside other db functions makes a single transaction?
Eso es usar el paradigma "procedural" o "funcional", en una base de datos. Yo lo hago todo el tiempo, literalmente manejo todo desde la base de datos, en el frontend solo hay; labels, layouts, textboxs y botones (pocos, porque no confío en los usuarios/humanos). El resto... Desde la vase de datos ❤ (Toma en cuenta que Postgres es una de las bases de datos más pulidas que existen)
Entonces... Cuando le haces ing. Inversa a mi App/ programa, solo te encuentras con un cascarón vacío.
Y de ahí a romper/hackear el Api y el server... Es un trabajo que bo cualquiera podría llegar a lograr (Sobre todo, si manejaste bien las Funciones y sus argumentos, RLS, Gatillos, Roles, Permisos, etc.)
Aunque no lo creas... Con Appinventor + Supabase; e creado "MVP's" más, eficientes, eficaces y seguros que el producto final de un equipo de "programadores", con 160k de usuarios conectados simultáneamente, con más de 40k de transacciones por segundo (con datos ultra confidenciales). [Sin usar autenticación, JWTs, Oauth, etc].
Solo porque se manejarme con la base de datos.
No
Struggling to find the documentation around the `client.query` API the way transactions are shown in early part of this video. Is that API documented on the Supabase docs site?
Can you use, and does it make sense, to use Postgres functions for Auth table?
Great video. Is there any way to manage these functions via your git repo and have them update on push or merge to master? Now that would make me use them much more and maybe some day will be possible if not already
It depends on your project setup, but at the end of the day these functions are written in plain SQL in files that live in your project repo, possibly next to all your other SQL scripts. You can use any migration tool you’re familiar with to add them to Supabase. Just make sure to drop the previous version of any function you’re updating before applying the new ones.
yes, you should be using supabase migrations framework which allows you to easily keep local/staging/prod up to date with your functions and schema changes.
How do we revert if one transaction fails?
Hello, how are you? I created a function and I'm calling it using RPC:
let { data, error } = await supabase.rpc('get_products_for_establishment', {
establishment_id: 1,
});
if (error) console.error(error);
else console.log(data);
But I'm encountering this error:
Argument of type 'string' is not assignable to parameter of type 'never'.
Thanks Jon. How does putting it inside a function make it into an atomic transaction? What happens if that first insert fails how does it know to roll back?
This is a great question. I'm not convinced that just putting statements in a function "conveniently" wraps them in a transaction. My understanding was that the function runs within the transactional context of whatever is executing the function. Perhaps supabase RPC begins and commits the transaction? It's important because if the intention of the function is to encapsulate a transaction perhaps it's better to do it explicitly in the function body.
@@michaeldausmann6066from the postgres docs: PostgreSQL actually treats every SQL statement as being executed within a transaction. If you do not issue a BEGIN command, then each individual statement has an implicit BEGIN and (if successful) COMMIT wrapped around it. A group of statements surrounded by BEGIN and COMMIT is sometimes called a transaction block.
so triggering the function executes it within a transaction. It's easy enough to try it out to verify.
@supabase @jon
@@joshuaowusu-ansah5142 would love to hear some more about this feature too, I can't find anything about it in the docs
Is it possible to declare a transaction outside of a db function?
Postgre es mi sistema operativo favorito. ❤❤❤
Yes.SQL commit
the problem is its so sick! to write another language than calling a transaction api like what firebase is doing
Postgres has also a really cool way to tell if the previous query returned null.
If not found then
I don't want to perform business logic in the database function, as it is not good for maintainability.
A video show how to do table joins in supabase postgres functions would be really appreciated
Great video as always. Thank you, sir.
So no second video on the auth?
Doing a "rollback" in an "EdgeFunction" would be awesome
I find it way to complicated to create functions and it is such a bad experience. Would be nice to have solution inside the application code. Since those functions also hold valuable information about the logic and what the app actually does.
This is way too involved. I just want to call a native transaction function from my swift client like Firebase. I don't have time for the rest...
A bigger issue with the app-side transaction management approach than coding mistakes IMO is there's no guarantee your code completes. Worst case the VM loses power unexpectedly. Although the recent crop of durable execution platforms such as Golem Cloud could mitigate that.
One thing Id like to see from ms sql coming to supabase is temporal tables 🎉❤
Slow down just a little bit. Your contents really-really good..
So good! Thanks!
Postgre es mi sistema operativo favorito 😂 ¿Sabías que puedes jugar Doom en Postgre?
Y Supabase es palabra mayor ❤ porque solo apareció, de la nada! Y todo aquel que buscaba oro en encontró Adamantium y Vibranium en un solo lugar.
¿Qué clase de comentario retardado es este?
He is awesome 💥
that lower casing ocd
🔥
I like that he wobbles like a jelly non stop
supabase is the future believe or not
tysm