Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postgres IDE in VS Code

techcommunity.microsoft.com

Post reply on HN
Print view View original

411–420 of 433 posts

Re: Postgres IDE in VS Code

#411

Post by pamelafox »

dzonga wrote: post #410
pamelafox wrote: post #255

Earlier quoted context omitted.

I'm a developer advocate at Microsoft, and from my perspective, both teams have been putting in a bunch of effort improving their extensions. I participated in usability studies with both the teams behind the SQL Server extension and new PostgreSQL extension, and then once they were ready, I participated in bug bashes. Both teams seem to very much want developers to enjoy their tools, so please do send them feedback…

are we gonna get for sqlite ?

I think this extension is going to focus on PostgreSQL only. For SQLite, try the SQLTools extension.

Re: Postgres IDE in VS Code

#412

Post by ecb_penguin »

scott_w wrote: post #405
ecb_penguin wrote: post #392

Earlier quoted context omitted.

It's definitely not the right answer. It's actually the completely wrong answer. Services are slow, restrictive, and don't enjoy the benefits of an actual DBMS, like transactions. You also add additional dependencies and failure points.

This isn’t a discussion of whether you should use services or not, only what to do in the case where you do have separate services interacting with a schema. And, in this case, trying to maintain consistency with multiple apps accessing the DB directly can quickly turn into a nightmare. Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other.

> Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other.

All you've done is shifted the dependency and made extra work when schemas change. Now we have schema updates, _and_ service updates.

As I said, you give up transactions, performance, and flexibility. You also increase the workload, and increase failures. There is almost no good reason for what you're proposing.

Re: Postgres IDE in VS Code

#413

Post by throwaway7783 »

ecb_penguin wrote: post #412
scott_w wrote: post #405

Earlier quoted context omitted.

This isn’t a discussion of whether you should use services or not, only what to do in the case where you do have separate services interacting with a schema. And, in this case, trying to maintain consistency with multiple apps accessing the DB directly can quickly turn into a nightmare. Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other.

> Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other. All you've done is shifted the dependency and made extra work when schemas change. Now we have schema updates, _and_ service updates. As I said, you give up transactions, performance, and flexibility. You also increase the workload, and increase failures. There is almost no good reaso…

I am not sure I understand. The context was multiple applications managing/accessing the same database. No matter how you slice it, a schema update is accompanied by application updates. If anything, in a service oriented approach, you can potentially isolate the impact by versioning APIs and writing compatibility logic in a single place.

Re: Postgres IDE in VS Code

#414

Post by ecb_penguin »

throwaway7783 wrote: post #413
ecb_penguin wrote: post #412

Earlier quoted context omitted.

> Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other. All you've done is shifted the dependency and made extra work when schemas change. Now we have schema updates, _and_ service updates. As I said, you give up transactions, performance, and flexibility. You also increase the workload, and increase failures. There is almost no good reaso…

I am not sure I understand. The context was multiple applications managing/accessing the same database. No matter how you slice it, a schema update is accompanied by application updates. If anything, in a service oriented approach, you can potentially isolate the impact by versioning APIs and writing compatibility logic in a single place.

> a schema update is accompanied by application updates

1. DB -> App = Two updates, the schema and the app

2. DB -> Service -> App = Three updates, the schema, the service, and the app

In both cases, obviously the DB changes.

In both cases, obviously the App changes.

In the second case, you also get to update your services.

Re: Postgres IDE in VS Code

#416

Post by scott_w »

ecb_penguin wrote: post #412
scott_w wrote: post #405

Earlier quoted context omitted.

This isn’t a discussion of whether you should use services or not, only what to do in the case where you do have separate services interacting with a schema. And, in this case, trying to maintain consistency with multiple apps accessing the DB directly can quickly turn into a nightmare. Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other.

> Better to maintain separate services interacting over some contract to insulate multiple codebases from the internals of each other. All you've done is shifted the dependency and made extra work when schemas change. Now we have schema updates, _and_ service updates. As I said, you give up transactions, performance, and flexibility. You also increase the workload, and increase failures. There is almost no good reaso…

Except if your schema changes in a way that forces your API contract to change, you have a big red alarm to tell you to investigate what’s using that contract and update it too.

When your apps connect to a DB schema, the change is silent. You just run ALTER TABLE and… whoops, you just brought down a service you didn’t know existed because the contract was implicit.

Re: Postgres IDE in VS Code

#417

Post by scott_w »

ecb_penguin wrote: post #414
throwaway7783 wrote: post #413

Earlier quoted context omitted.

I am not sure I understand. The context was multiple applications managing/accessing the same database. No matter how you slice it, a schema update is accompanied by application updates. If anything, in a service oriented approach, you can potentially isolate the impact by versioning APIs and writing compatibility logic in a single place.

> a schema update is accompanied by application updates 1. DB -> App = Two updates, the schema and the app 2. DB -> Service -> App = Three updates, the schema, the service, and the app In both cases, obviously the DB changes. In both cases, obviously the App changes. In the second case, you also get to update your services.

No, it’s not obvious the DB changes because the team depending on that schema doesn’t necessarily talk to your team much, and you might not even know that team exists.

The same is true for API contracts but the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed.

Re: Postgres IDE in VS Code

#418

Post by ecb_penguin »

scott_w wrote: post #417
ecb_penguin wrote: post #414

Earlier quoted context omitted.

> a schema update is accompanied by application updates 1. DB -> App = Two updates, the schema and the app 2. DB -> Service -> App = Three updates, the schema, the service, and the app In both cases, obviously the DB changes. In both cases, obviously the App changes. In the second case, you also get to update your services.

No, it’s not obvious the DB changes because the team depending on that schema doesn’t necessarily talk to your team much, and you might not even know that team exists. The same is true for API contracts but the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed.

> No, it’s not obvious the DB changes because the team depending on that schema doesn’t necessarily talk to your team much, and you might not even know that team exists.

Literally everything you just said applies to services and API contracts as well. You haven't solved anything.

> the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed

You're just making this up. There are thousands of incidents every day because someone changed an API without communicating to every stakeholder.

"Services are better than databases because service owners are better at communicating changes than database owners" isn't a very compelling argument.

I'd work to fix the communication problem before I adopted a terrible tech solution.

Re: Postgres IDE in VS Code

#419

Post by scott_w »

ecb_penguin wrote: post #418
scott_w wrote: post #417

Earlier quoted context omitted.

No, it’s not obvious the DB changes because the team depending on that schema doesn’t necessarily talk to your team much, and you might not even know that team exists. The same is true for API contracts but the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed.

> No, it’s not obvious the DB changes because the team depending on that schema doesn’t necessarily talk to your team much, and you might not even know that team exists. Literally everything you just said applies to services and API contracts as well. You haven't solved anything. > the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed You're jus…

>> the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed

> You're just making this up. There are thousands of incidents every day because someone changed an API without communicating to every stakeholder.

What you wrote isn't a contradiction of what I wrote. I wrote "more understood" not "perfectly solved problem."

> "Services are better than databases because service owners are better at communicating changes than database owners" isn't a very compelling argument.

Except they are because the tooling is better. I can check calls to an API endpoint using the same tooling that I would for checking end user API calls. I can push out comms to use the new API, I can confirm calls go to 0 before deleting the old endpoint.

For checking that a table or column is being accessed before changing / deleting it? Fuck, I don't actually know how I'd orchestrate that. And once I've made that change (vs when I make an API change), well, I hope I got it 100% correct because reverting that change is harder.

Re: Postgres IDE in VS Code

#420

Post by netghost »

seveibar wrote: post #163
netghost wrote: post #107

Earlier quoted context omitted.

That seems like a really pragmatic tool, thanks for sharing it! I'm curious, do you output triggers, store procedures, and such? Many tools seem to stop after you've defined tables, columns, and indices, but I'd love some better tooling to make use of the rest of the DB's features.

Yep! It basically runs pg_dump and categorizes all of the output into different files so it should be comprehensive. I think there's `functions/function_name.sql`, `misc.sql`, `triggers.sql` etc.

Thanks!

And curses. Now I'm going down another rabbit hole rehashing ways to interface with my database in a side project that is doomed to never get past the "there has to be a better way to…" phase ;)

Post reply on HN