Rule #1: Always start with PostgreSQL unless you have a very compelling reason not to.
Why not something even simpler like H2?
Java dependency.
Red Hat Satellite to standardize on PostgreSQL backend
261–270 of 298 posts
Re: Red Hat Satellite to standardize on PostgreSQL backend
#262Earlier quoted context omitted.
Look at GraphQL. It lets you enforce a single schema from the front end down to the data layer. In my company's product, we specify the data models as JSON Schema, and then generate the necessary language code -- we generate the GraphQL schema from it as well as Go data types, with some database glue. Our front end code is currently JavaScript, but we hope to migrate to TypeScript, which will make everything statical…
https://github.com/grpc/grpc-web
Yes, you can make it work. But you have to run this special shim or proxy, because browsers still don't all support HTTP/2, header trailers, etc. Hence "lacking".
Re: Red Hat Satellite to standardize on PostgreSQL backend
#263Earlier 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…
That seems like good advice for smaller-scale web development, and extremely good advice for single-user applications. If you're working on a larger scale, or expect to be growing into a larger scale, though, then I think it's wise to skip straight to using a full-blown RDBMS. It's not about scalability, per se - very, very few projects need more performance than SQLite can deliver - so much as about manageability. A…
I really like Firebird's model where you can either access a database file directly (like SQLite) or through a server process (like Postgres). Switch anytime you want. Best of both worlds. How lovely it would be if Postgres were to support something like that.
Re: Red Hat Satellite to standardize on PostgreSQL backend
#264Earlier quoted context omitted.
A way to think about that question is to ask whether typelessness in general is bad because a lot of the schemaless databases come from that side of the divide. I’d personally answer yes, but that’s because I believe that typed, schema-generates structures should be pushed all the way from the database to the typescript code on the front end. Changes become something you can deal with with high confidence and things…
how do you do this? tie it all the way from the DB to the client? incidentally I believe this is the difference between being an engineer and being a product person. I straddle the line. in theory I want a strong type system so I can be confident about the future. in practice I don't want to pay the upfront cost and I'm more interested in shipping now and taking on debt.
We wrote it. Everything is derived from proto for us. Some of that is hand-written tooling, some is off the shelf. Mostly you have to be aware at design time of what this approach entails.
Proto is not elegant and the data model and implementation (especially the very poor performance of maps in the Go implementation) can leave a lot to be desired, but it's a thing that pretty much supports everything. It has good enough performance without headaches. Lowest common denominator can be quite useful and so can constraints.
Re: Red Hat Satellite to standardize on PostgreSQL backend
#265A 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…
> How do I store it? To me, NoSQL seemed like the choice in the past. If you're using postgres, you could use a column of type jsonb. Postgres comes with many operators and functions ( https://www.postgresql.org/docs/11/functions-json.html ) to query into jsonb typed columns and many of them even allow index usage for very quick access. However, the other option would be to use proper SQL tables and normalization to…
Or you can store the jsonb in Postgres and use views to also present it in a normalized way. See example here: https://www.endpoint.com/blog/2016/02/29/converting-json-to-...
Re: Red Hat Satellite to standardize on PostgreSQL backend
#266Earlier 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…
Yup this. People don't realize just how performant SQLite can be. If you are running just 1 server and won't probably need more than SQLite is more than enough. 2 application servers and up is where PostgreSQL can come into play. https://www.sqlite.org/whentouse.html After reading the SQLite when-to-use document I transitioned some smaller marketing sites over from Postgres because it was overkill for the specific si…
But postgresql gives you not just the standard SQL database. It also does pubsub, timeseries, and lots more. It's fairly lean in itself and does not induce much overhead. Can run locally just with a unix socket and thus be just as easy as sqlite.
Re: Red Hat Satellite to standardize on PostgreSQL backend
#267Earlier 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…
"popular format", sqlite, Postgres are quite sensible. My personal mix also contains rockdb (lmdb is interesting, didn't use yet) and redis, as potential alternatives for sqlite and Postgres, depending on the use case.
You can actually use postgresql for pubsub and thus instead of redis in some use cases.
Re: Red Hat Satellite to standardize on PostgreSQL backend
#268Earlier quoted context omitted.
How exactly would you corrupt it? For all the stuff that's in-memory, it's as safe as your language is. If you're writing it to disk all at once, it's easy to implement this atomically with rename - this guarantees that you have either the old file or the new file, but not some weird in-between state. And if you mean corrupting by the app going amok and asking to corrupt data because of logic errors in the app itself…
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 things that you've listed are advanced features, and all of them have some trivial equivalent for in-memory data.
Side note: do you maybe have an image of a very particular kind of app in mind? Like, a moderately sized web app? Keep in mind that I'm talking in general here, about web/desktop/mobile, and about all sizes. And in practice, even for web apps, people often underestimate the actual usage and perf requirements.
Re: Red Hat Satellite to standardize on PostgreSQL backend
#269Earlier quoted context omitted.
How exactly would you corrupt it? For all the stuff that's in-memory, it's as safe as your language is. If you're writing it to disk all at once, it's easy to implement this atomically with rename - this guarantees that you have either the old file or the new file, but not some weird in-between state. And if you mean corrupting by the app going amok and asking to corrupt data because of logic errors in the app itself…
I had a python script that was roughly: read file, unpickle, do stuff in memory, pickle, write. A bug in "do stuff in memory" could easily muck things up and I didn't get round to renaming the file for every edit. Yeah you could do some auto rename thing but it might be simpler to just use sqlite.
> I didn't get round to renaming the file for every edit.
That was your problem then, no? If you don't do that from the get go, you're essentially saying that you don't care about atomicity, consistency and durability.
> Yeah you could do some auto rename thing but it might be simpler to just use sqlite.
You mean atomic rename? The simplest way is to just use a library that does it for you. One does exist for Python. It takes 2 lines of code to safely dump your JSON data with it.
Re: Red Hat Satellite to standardize on PostgreSQL backend
#270Earlier 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?
Yea, that seems frightening. I like to think of my local variables as my inaccessible local state. I'd imagine it keeps my JIT happy too. What would it even mean to have a lambda reference to a variable who's stack frame has already popped?