3 ms·

I agree, but I also see the benefits from the other side, so I’ll play devil’s advocate: - it is cached, in the database’s memory, where the cache can be inval

by Joeri 7y ago

I agree, but I also see the benefits from the other side, so I’ll play devil’s advocate: - it is cached, in the database’s memory, where the cache can be invalidated automatically. It is better to cache views than data anyway. - it is portable to every platform postgres runs, which in practice means it will run everywhere. Portability between databases is overrated because it rarely happens in practice. - the access control logic evolves together with the schema, guaranteeing they have an exact correspondence. This is a good thing. - integration tests should involve a live database - have you looked at jetbrains datagrip?

sscarduzio 7y ago
The tooling is just fine for me, DataGrip or not: I wrote a ton of PostgreSQL triggers and utility functions in Javascript thanks to the excellent plv8 (free) extension. Development and unit tests for these functions is as easy as plain Javascript.
- BiteCode_dev 7y ago
  > Development and unit tests for these functions is as easy as plain Javascript. Since most popular product in the JS world are product to avoid writing Javascript (webpack+babel, typescript, coffeescript, jsx, etc), and plv8 supports non of that nor does it support standard unit tests framework like Jest, I'm not convinced. To make things even worst, remote debugging is not supported anymore: https://github.com/plv8/plv8/issues/131#issuecomment-237711101 https://github.com/plv8/plv8/issues/131#issuecomment-2377111...
  - sscarduzio 7y ago
    I personally this time around, I found no need to even use a framework for unit testing a single javascript function. If I had to do something that feels too complex, I'd write some interfaces in TypeScript to represent the tuples, then implement the function in TS, and compile it into plain JS in order to deploy it to plv8.
BiteCode_dev 7y ago
> it is cached, in the database’s memory, where the cache can be invalidated automatically. It is better to cache views than data anyway. The cache may not be for the data in the data base, but for something else (task queue, calculation, user session, pre-rendering, etc). You effectively split your cache into several systems. > it is portable to every platform postgres runs, which in practice means it will run everywhere. Portability between databases is overrated because it rarely happens in practice. As I mentioned, for a project it doesn't matter. For a lib it does. > the access control logic evolves together with the schema, guaranteeing they have an exact correspondence. This is a good thing. Not always. Your access control logic could be evolving with your model abstraction layer, which frees you to make changes to the underlying implementation without having to change the control logic every time. It's also a good for your unit tests, as they are not linked to something with a side effect. > integration tests should involve a live database Integration tests are slow. You can run them as you develop. > Have you looked at jetbrains datagrip? It's fantastic. If you are willing to pay the price of it for and force it on your entire team. If you are on an open source project, will your expect that from all your contributors ? High barrier of entry, with no modularity. Linters, formatters, debuggers, auto-importers, they all depend on that one graphical commercial product that is not integrated with your regular IDE and other tools. Not to say it's not a good editor if you do write a lot of SQL, as JetBrains products are always worth their price.

by Joeri 7y ago

sscarduzio 7y ago

The tooling is just fine for me, DataGrip or not: I wrote a ton of PostgreSQL triggers and utility functions in Javascript thanks to the excellent plv8 (free) extension. Development and unit tests for these functions is as easy as plain Javascript.

BiteCode_dev 7y ago
> Development and unit tests for these functions is as easy as plain Javascript. Since most popular product in the JS world are product to avoid writing Javascript (webpack+babel, typescript, coffeescript, jsx, etc), and plv8 supports non of that nor does it support standard unit tests framework like Jest, I'm not convinced. To make things even worst, remote debugging is not supported anymore: https://github.com/plv8/plv8/issues/131#issuecomment-237711101 https://github.com/plv8/plv8/issues/131#issuecomment-2377111...
- sscarduzio 7y ago
  I personally this time around, I found no need to even use a framework for unit testing a single javascript function. If I had to do something that feels too complex, I'd write some interfaces in TypeScript to represent the tuples, then implement the function in TS, and compile it into plain JS in order to deploy it to plv8.

BiteCode_dev 7y ago

> it is cached, in the database’s memory, where the cache can be invalidated automatically. It is better to cache views than data anyway. The cache may not be for the data in the data base, but for something else (task queue, calculation, user session, pre-rendering, etc). You effectively split your cache into several systems. > it is portable to every platform postgres runs, which in practice means it will run everywhere. Portability between databases is overrated because it rarely happens in practice. As I mentioned, for a project it doesn't matter. For a lib it does. > the access control logic evolves together with the schema, guaranteeing they have an exact correspondence. This is a good thing. Not always. Your access control logic could be evolving with your model abstraction layer, which frees you to make changes to the underlying implementation without having to change the control logic every time. It's also a good for your unit tests, as they are not linked to something with a side effect. > integration tests should involve a live database Integration tests are slow. You can run them as you develop. > Have you looked at jetbrains datagrip? It's fantastic. If you are willing to pay the price of it for and force it on your entire team. If you are on an open source project, will your expect that from all your contributors ? High barrier of entry, with no modularity. Linters, formatters, debuggers, auto-importers, they all depend on that one graphical commercial product that is not integrated with your regular IDE and other tools. Not to say it's not a good editor if you do write a lot of SQL, as JetBrains products are always worth their price.