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

161–170 of 298 posts

Re: Red Hat Satellite to standardize on PostgreSQL backend

#161

Post by manigandham »

shanemhansen wrote: post #122
fyfy18 wrote: post #97

Earlier quoted context omitted.

It sounds more like an edge case though. I can't imagine all the data you need to store may or may not be the right format, so I wouldn't switch my database just because one or two entities need this. Anyway this is 2019 so PostgreSQL JSONB fields have got you covered. You can even efficiently query the JSON objects within them.

Unlogged jsonb tables in postgres have generally made nosql systems look pretty bad. I'm really happy the industry finally came up with vitesse so we could have a middle option between "My ACID database needs to scale writes so I'll roll my own fragile sharding layer" and "give up all attempts at schema and consistency and transactions". Vitess is a really comfortable middle ground of fairly familiar database semanti…

Same with Citus for Postgres. Or CockroachDB / TiDB for a rebuilt natively-distributed modern RDBMS.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#162

Post by manigandham »

pjmlp wrote: post #113
int_19h wrote: post #36

Earlier quoted context omitted.

Java did it way too slow, and that is a significant contributor to it being relegated to "legacy" in many areas. If it waited for the other languages to prototype stuff, it might have not been the case. The problem is that it waited for them to prototype it, refine it, release it, popularize it, and for their community to adopt it, before even starting to work on it in Java - which means that by the time they had it,…

Looking around the office and my phone, Java is anything but "legacy". As for alternative JVM languages, while they are cool and have brought many fresh ideas into the platform, they remain a very tiny portion of the Java developers' market. Java takes a very long time, because backwards compatibility and cooperation among giant companies takes years. C# has basically Microsoft deciding how the roadmap looks like and…

Runtimes are different from languages. The C# language has never been rebooted and is fully backwards compatible, and there's no better example of long-term support than Microsoft. You can still run apps from the MSDOS era, and even upgrade MSDOS through to Windows 10 if you have all the CDs today.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#163

Post by manigandham »

eropple wrote: post #96
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.

C# lets you do that because C# doesn't have a way to declare a local readonly/final variable at all . I significantly prefer features that encourage the use of `final` variables everywhere that it is possible in Java. I write C#, Java, and Kotlin in roughly equal measure. Each has its pluses. But the claim that Java's lambdas are worse because it doesn't let you--and this was a conscious design choice!--do something…

I rather be able to do something than be prevented because someone somewhere thinks that it's "potentially catastrophic". That seems especially hyperbolic in this case.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#164

Post by sandGorgon »

willvarfar wrote: post #159
sandGorgon wrote: post #158

Earlier quoted context omitted.

postgres has a jsonb datatype that works pretty much like mongodb. https://blog.codeship.com/unleash-the-power-of-storing-json-...

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.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#165

Post by pjmlp »

manigandham wrote: post #162
pjmlp wrote: post #113

Earlier quoted context omitted.

Looking around the office and my phone, Java is anything but "legacy". As for alternative JVM languages, while they are cool and have brought many fresh ideas into the platform, they remain a very tiny portion of the Java developers' market. Java takes a very long time, because backwards compatibility and cooperation among giant companies takes years. C# has basically Microsoft deciding how the roadmap looks like and…

Runtimes are different from languages. The C# language has never been rebooted and is fully backwards compatible, and there's no better example of long-term support than Microsoft. You can still run apps from the MSDOS era, and even upgrade MSDOS through to Windows 10 if you have all the CDs today.

Runtimes and languages go hand-in-hand, a runtime that doesn't support everything that one expects from the standard library breaks compatibility.

Code starts getting full of #ifdefs

Siverlight, .NET Core, WinRT, UWP just to give three reboots.

No support for dynamic APIs, appdomains, IL generation on the fly, reflection APIs done in a different way, ...

Actually C# is not fully backwards compatible, variables declared on foreach statements changed their semantics in C# 5.

https://blogs.msdn.microsoft.com/ericlippert/2009/11/12/clos...

MS-DOS is only supported in 32 bit variants, a species in extinsion.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#166

Post by PurpleRamen »

sandGorgon wrote: post #158
BossingAround wrote: post #157

A silly, genuine question: when I'm writing a NodeJS app, and I need to store a JSON in a DB that looks like this: { "a" : "b", "c" : { "ca":"cb", "cd":"ce" }, "d": { ... } } How do I store it? To me, NoSQL seemed like the choice in the past. This is not difficult in relational DBs, but it requires rather long SQL commands, and SQL table design. It seems to me that "MongoDB.insert(obj)" seems like the way to go, as i…

postgres has a jsonb datatype that works pretty much like mongodb. https://blog.codeship.com/unleash-the-power-of-storing-json-...

But will it perform as good as a dedicated nosql-db? Will the abilitys match? The querys? There usually is a tradeoff when something is forced into something alien. Is this the case here too?

Re: Red Hat Satellite to standardize on PostgreSQL backend

#167

Post by pjmlp »

int_19h wrote: post #146
pjmlp wrote: post #113

Earlier quoted context omitted.

Looking around the office and my phone, Java is anything but "legacy". As for alternative JVM languages, while they are cool and have brought many fresh ideas into the platform, they remain a very tiny portion of the Java developers' market. Java takes a very long time, because backwards compatibility and cooperation among giant companies takes years. C# has basically Microsoft deciding how the roadmap looks like and…

And yet Google is investing into Kotlin. Yes, Java takes it slow because its target market - enterprises - want it, and they have good reason to. There's nothing wrong with that. All I'm saying is that there are many other niches where developers find lagging too far behind other available options, and there's a noticeable decline in its use because of that. And so the analogy with PostgreSQL in this case isn't worki…

Google is investing into Kotlin due to politcs with Oracle, and JetBrains (makers of InteliJ which powers Android Studio) pushing Kotlin everywhere they can.

They even separate Kotlin/Native graphical debugging from InteliJ, so that developers get to shell out for Clion license as well.

The only variant where InteliJ and Clion come together is on Android Studio, thanks to us NDK users being vocal how 3rd class it felt versus Eclipse CDT.

On platforms where developers can make use of standard Java there is less pressure to adotpt alternative JVM languages.

Just like F# will always be a shadow of C#, never getting to play with all toys, with C# slowly picking up all features that matter.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#168

Post by garyclarke27 »

int_19h wrote: post #135
sonnyblarney wrote: post #101

Earlier quoted context omitted.

"data is data, it's either valid, or it's not. That's why the schema is about the data, not about the app." This is not true. The objective of the overall app/system (i.e. front/back/middle/DB/storage/services etc.) is to carry out some kind of business logic. A DB schema cannot fully validate stored data against the logic. Otherwise we wouldn't write backend code, we'd just write a bunch of schemas and be done with…

> The DB may only care that it's UTF and max 20 chars. But the system requires more validation than that. Are you familiar with SQL constraints, triggers, user-defined functions, stored procedures?..

Yes + Postgres has Domains which are very nice, especially if you use only Functions for data insert (which i do) This gives you more granularity, than a domain on a Column. Domians are like Dependent Types, offering very fine grained control, enforced by RegEx, functions, enums, even lookup functions are ok so long as lookup tables are stable.

Re: Red Hat Satellite to standardize on PostgreSQL backend

#169

Post by oblio »

ajcodez wrote: post #50
djrobstep wrote: post #41

Earlier quoted context omitted.

My pet theory is that NoSQL took off purely because people were sick of having to manage schema changes. Unfortunately, people reacted to being (justifiably) frustrated with schemas by throwing strict schemas out entirely, instead of making better schema management/migration tools.

I think it also has to do with the source of data. If you receive data from a third party it’s easy to insert the whole document and figure out what parts you need later. If your data comes from your own client interface it makes more sense to build up the data model over time.

You could just plonk the data in a JSONB, BLOB or just plain old file on a disk with a URL pointing to it while you figure it out. And not introduce another super complex to support dependency...

Re: Red Hat Satellite to standardize on PostgreSQL backend

#170

Post by dchest »

int_19h wrote: post #93
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?

You create a JSON (for example) for all your users when you need to store it. But in memory, it's just a collection of User objects - or whatever is idiomatic for your PL. And you query it with the same tools your language offers - e.g. sequence comprehensions. So there's no impedance mismatch, and no need for the vastly more complicated code that is needed to bridge it. Even if it's not your code - i.e. if you're us…

Unfortunately, I've rarely seen such a simple thing as file saving implemented correctly by many developers. Missing fsync(), missing checking of errors on close(), in-place non-atomic data overwrites. One of the good things about using SQLite/Postgres/MySQL is that at least they save your data correctly.
Post reply on HN