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

281–290 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#281

Post by jacques_chester »

sonnyblarney wrote: post #63
jacques_chester wrote: post #35

Earlier quoted context omitted.

Databases are, as their name suggests, closest to the data. Applications generally can't recreate ACID properties and specifically, they shouldn't be trying to.

"Applications generally can't recreate ACID properties" - why would they? ACID and 'data validation' are generally separate issues. Data generally has to be validated as it enters the business logic, before it gets stored in a DB. While a DB may in some cases ensure that data adheres to a schema, this usually does not fulfill all of the validation requirements.

Validation often requires examine a model beyond "is this an int?". That model needs to be self-consistent. That requires atomic movements from consistent state to consistent state.

You can do that yourself. Or let the database do it. For things where you can't express it in a database schema, sure. But you'd be surprised how far it gets you.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#282

Post by int_19h »

chrisseaton wrote: post #172
int_19h wrote: post #83

Earlier quoted context omitted.

For example, in Java, lambdas cannot capture mutable variables from the outer scope - it must be final, or effectively final. C# always let you do that, from the very first implementation of lambdas.

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 intend to invoke lambdas concurrently can mark them as such, and then the language would enforce sharing, while other APIs that do not use lambdas in a concurrent context, can use their full power.

Same thing goes for lambdas that cannot escape vs those that can - if you reflect this in the type system, then you can also support safe nonlocal breaks and returns in the former, for example. One of the early Java lambda proposals, the one by Neal Gafter, did just that, and it was awesome.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#283

Post by pstuart »

ngrilly wrote: post #185
int_19h wrote: post #43

Earlier quoted context omitted.

Always start with in-memory data structure with straightforward persistence (i.e. load and save it all at once, using some popular format). If you need ACID, then start with SQLite. If you need scalability as well, then PostgreSQL. Most other features aren't worth the hassle of configuration compared to a single file on disk and a library to link to. (But I suspect that most NoSQL apps these days would do just fine w…

SQLite is really great, but as a datastore for a web app or a web service, it lacks a few important things to my eyes: - Cannot rename or drop column - Cannot create an index concurrently (without blocking writes) - No remote protocol (you have to use the CLI through SSH to run ad-hoc queries)

Column rename was added recently.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#284

Post by willvarfar »

philliphaydon wrote: post #224
willvarfar wrote: post #175

Earlier quoted context omitted.

Yeah MariaDB got 'dynamic columns' first, which iirc supported key values but not arrays, and then MySQL added a more complete 'json' data type, so the exact functionality differs by flavour and version. The postgres support is simply nicer to use and more powerful, e.g. the indexing. But if your RDBMS is any fairly-recent version of MariaDB or MySQL, you can use JSON too. Of the top of my head, the thing I find most…

Didn't PostgreSQL get hstore before MariaDB got dynamic columns?

Yeah I seem what I wrote could be ambiguous, but in that first para I was meaning to compare MariaDB and MySQL, not claim that MariaDB beat PostgreSQL.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#285

Post by ousta »

chrisseaton wrote: post #89
ousta wrote: post #85

Earlier quoted context omitted.

i struggle to see why in-memory data structure is the way to start can you please explain. do you create json for all your users?

> i struggle to see why in-memory data structure is the way to start can you please explain. It’s much simpler. The idea is to start simple and avoid complexity. Do you need the extra complexity of a PostgreSQL instance or can you get away with doing it in-memory? If so you can save yourself a lot of complexity.

surely you are using angular, nodejs or react right? why not just raw html and css? its much simpler

Re: Red Hat Satellite to standardize on PostgreSQL backend

#286

Post by webninja »

liquidise wrote: post #42
bane wrote: post #29

Rule #1: Always start with PostgreSQL unless you have a very compelling reason not to.

"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.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#287

Post by ngrilly »

pstuart wrote: post #283
ngrilly wrote: post #185

Earlier quoted context omitted.

SQLite is really great, but as a datastore for a web app or a web service, it lacks a few important things to my eyes: - Cannot rename or drop column - Cannot create an index concurrently (without blocking writes) - No remote protocol (you have to use the CLI through SSH to run ad-hoc queries)

Column rename was added recently.

Thanks! I missed this.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#288

Post by taffer »

twic wrote: post #219
anarazel wrote: post #202

Earlier quoted context omitted.

I don't see how you'd describe postgres validly as a key-value store at the storage level / internally. It's a pretty traditional row-store (without support for index oriented tables), i.e. all columns of a table are stored together. At the storage level there's no designation of what the key of a row is. Of course you can have primary keys, but that's a higher layer concern.

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" only means that it supports custom data types and inheritance, and at least custom data types are still a core feature of PostgreSQL.

[1] https://www.postgresql.org/docs/8.1/datatype-oid.html

Re: Red Hat Satellite to standardize on PostgreSQL backend

#289

Post by h1d »

nouveaux wrote: post #109
paxys wrote: post #102

Earlier quoted context omitted.

In-memory or local disk databases aren't going to work for any real world use case, regardless of how small or simple your application is. Using Postgres or MySQL is barely more complex than SQLite, and it makes more sense to start with one of them than move everything over once you realize you aren't going to be running on your dev machine forever.

After developing with Postgres for several years and then moving to sqlite for dev, sqlite is a breath of fresh air. Now our policy is that everything goes into sqlite db unless the data requires multiple writers. The fact that you have to keep a process running and updated is reason enough to not use Postgres if you can help it. For instance, we have processes that fetches and stores data from APIs. It's trivial to…

How do you browse the data on the remote server with any GUI tools?

Last time I checked not even DataGrip could do it.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#290

Post by h1d »

int_19h wrote: post #156
y4mi wrote: post #153

Earlier quoted context omitted.

I'm pretty sure he's taking about web application... Sqlite is only really viable if you don't have an undefined amount of nodes pushing commits into the DB That's a challenge desktop applications don't have

For many web apps it's true simply because of the expected usage, or sometimes because of access patterns (e.g. when most clients are read-only, or when most users don't author anything). From https://www.sqlite.org/whentouse.html : "The SQLite website ( https://www.sqlite.org/ ) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are…

How can you build and live with a page that runs 200 queries for every access?
Post reply on HN