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

Red Hat Satellite to standardize on PostgreSQL backend

redhat.com

Post reply on HN
Print view View original

291–298 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#291

Post by h1d »

webninja wrote: post #286
liquidise wrote: post #42

Earlier quoted context omitted.

"Very compelling reasons" means different things to different people. Which i suppose is a catch 22. The young but introspective dev may make the wrong call on a side project and learn to stick to psql in the future. The dev who is convinced "web scale" will arrive before their first AWS bill and picks Mongo as their production database will have a worse fate. As will their team and company by proxy. Rule #1: Always…

Is there a nice web interface that is made for PostgreSQL? I’m in love with the power that PHPMyAdmin brings to MySQL. Also there are DigitalOcean Ubuntu droplet images with it all pre-configured.

It always feels way snappier to use a local GUI connected through SSH than PhpMyAdmin and its interface also feels very cluttered to me.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#292

Post by chrisseaton »

int_19h wrote: post #282
chrisseaton wrote: post #172

Earlier quoted context omitted.

What’s the memory model for captured variables being mutated by multiple threads?

The same memory model as any other shared variable being mutated by multiple threads - you either explicitly synchronize, or you just don't do it. But given that lambdas are far from the only way to get there - and those other ways are already idiomatic in the language (e.g. statics) - why single out lambdas specifically for this? The ideal solution is to make this a part of the function type - so that APIs that do i…

> why single out lambdas specifically for this?

Because existing memory models have rules for object fields and rules for publishing objects.

These rules don’t apply to local variables.

They could do - but that’s what I’m asking.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#293

Post by johannes1234321 »

sandGorgon wrote: post #164
willvarfar wrote: post #159

Earlier quoted context omitted.

And other regular RDBMS like MariaDB and MySQL have much the same functionality. I store JSON in RDBMS all the time.

interesting - i never knew that. I use postgresql, so dont have first hand knowledge, but i saw this https://tableplus.io/blog/2018/09/mariadb-vs-postgresql-a-qu... > JSON support: PostgreSQL supports JSON and JSONB while MariaDB doesn’t. It supports an alias for JSON instead, which is a LONGTEXT column. Even the proposed json column, is not indexed - postgresql jsonb is indexed and queries fast.

Ntoe that MySQL's `JSON` type is using an efficient binary storage scheme which allows fast lookups etc. https://dev.mysql.com/doc/refman/8.0/en/json.html

My favorite MySQL JSON feature probably is JSON_TABLE which converts a JSON document on the fly into a table which can hen be processed using SQL features. https://dev.mysql.com/doc/refman/8.0/en/json-table-functions...

(Disclaimer: I work for Oracle's MySQL Engineering team)

Re: Red Hat Satellite to standardize on PostgreSQL backend

#294

Post by chasd00 »

matwood wrote: post #220
chasd00 wrote: post #105

Earlier quoted context omitted.

also, DBAs hate developers. Developers want to make changes to the database to support their classes such as "i need to add a column" and the DBA response is "no." or, even worse, "fill out this ticket and it will get prioritized in the next scrum" meanwhile the developer is at a standstill. I interviewed at southwest airlines years ago and i don't remember how it came up but we were talking about bottlenecks or some…

I think you need to also look at it from the DBAs stand point. If they did whatever the developers want and the system goes down or more likely other parts become slow, it is the DBA who gets the call. In a large company like SW, the developer requesting some change for their app may have no idea how else the db is being used. What if their requested changes took down the db and prevented reservations from working? M…

Took me a while to get back here but I do understand your point and it's totally valid. That door swings both ways.

That's why it's hard for the two camps to work side by side.

NoSql gave power to the devs at the expense of the experience and wisdom of the database folks. I bet many many applications and systems were completely screwed datawise more than once because of devs and NoSql.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#295

Post by anarazel »

taffer wrote: post #288
twic wrote: post #219

Earlier quoted context omitted.

Aren't tables a bit like key-value stores where the key is an object ID and the value is the column values? My understanding is very vague, but i think that came out of PostgreSQL's heritage as an "object-relational" database, even if it's vestigial today.

Since 8.1 PostgreSQL does not work this way anymore. The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables. [1] Besides, "object-relational" on…

And in PG 12 we've removed the magic oid columns (as in WITH OIDS), although you can still create one manually (but there'll not be any values assigned automatically).

Re: Red Hat Satellite to standardize on PostgreSQL backend

#296

Post by jeffdavis »

int_19h wrote: post #268
jeffdavis wrote: post #259

Earlier quoted context omitted.

Create some ID that's supposed to be unique, and due to a race condition, it's not. Then, before you know it, the data is a mess. Unique keys, foreign keys, check constraints, and DDL changes were all meant to solve real problems. I guess some apps might not benefit as much, but it seems like asking for trouble. Given how easy it is to just use postgres, why invite all the risk?

If your data is in-memory, why would you have IDs and foreign keys? You'd just have objects referencing other objects (or maps referencing maps, or whatever is idiomatic). I wasn't talking about re-implementing a relational database in-memory, but simply working with data in the way that is natural in your language. If you do actually need advanced schema features, then I agree, just use PostgreSQL. But none of the t…

If you make code changes, that usually means you need to adjust your data structures, too. That means you need to manage multiple on disk versions, or maybe migrate the old data to the new version.

I mean, you can do all of this stuff another way. But PostgreSQL represents a lot of lessons learned over decades with all kinds of applications.

Sure, there may be some level at which it's just easier to serialize the in-memory data. But that level is lower than most people realize and postgres is pretty darn easy to use given all the kinds of problems it helps you avoid.

Even an MVP of a trivial web app is probably fastest to deliver with postgres, and less risky.

And there are tons of things that are really convenient even for the tiniest app. For instance, being able to go in and browse your data to find out what's causing a minor bug.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#297

Post by int_19h »

kevin_thibedeau wrote: post #258
int_19h wrote: post #132

Earlier quoted context omitted.

But the only file handling stuff you need to load JSON from a file is to open the file. And if it's in SQLite, then you'll need to open the database and query - more complicated, no?

Open the file, parse its content, deal with any errors. SQLite is simpler.

Opening the file and parsing JSON in it is two lines of code in Python.

Errors can happen in both cases - you can have a corrupt SQLite DB, just as you can have invalid JSON. The way you handle them is pretty much identical.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#298

Post by matwood »

chasd00 wrote: post #294
matwood wrote: post #220

Earlier quoted context omitted.

I think you need to also look at it from the DBAs stand point. If they did whatever the developers want and the system goes down or more likely other parts become slow, it is the DBA who gets the call. In a large company like SW, the developer requesting some change for their app may have no idea how else the db is being used. What if their requested changes took down the db and prevented reservations from working? M…

Took me a while to get back here but I do understand your point and it's totally valid. That door swings both ways. That's why it's hard for the two camps to work side by side. NoSql gave power to the devs at the expense of the experience and wisdom of the database folks. I bet many many applications and systems were completely screwed datawise more than once because of devs and NoSql.

To be clear, I've known DBAs who act exactly like you described in your original comment. Very annoying.

The best I've seen it work is to have a DBA on the team building the application.

Post reply on HN