Aijan

I think this page explains it well: https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch

Perhaps I was unclear. What I meant to say is that, whenever possible, we shouldn't have multiple versions of a field, especially when there is no corresponding plaintext password field in the database, as is the case here.

Thanks for the tip. password.trim() can indeed be problematic. I just removed that line.

Seriously, why the negative tone? If I've offended you, I'm sorry. You might think that I'm wasting time, but there are multiple ways to skin a cat. I prefer not to use DEB packages for deployment, though others might.

Cleanup can be as simple as deleting the latest deployment directory, if the script gets that far. The article is about using built-in Linux tools for 'easy' application deployments. One can also use dedicated tools, as you suggested, to further automate the deployment process.

Author here. In case it’s not clear, this article isn't about installing Linux packages; it's about deploying multiple versions of software to development and production environments.

Author here. My blog is also generated with Hugo, and it's great. I just prefer not to generate HTML and CSS from JavaScript unless it's necessary.

Sorry, I haven’t seen that movie. Thanks for the recommendation though.

That idea crossed my mind too, but you can’t really use the full capabilities of SQL in graph databases, and that’s a deal breaker for me.

There's certainly the danger of creating too many ad-hoc or sparse relationships, which can cause issues. That said, when used for supplementing foreign keys, Tie-in can be a useful tool in a production system as well.

Yes, that's correct. Here's how an entry in the join table looks like:

{
  "id": 6,
  "sourceComp": "user",
  "sourceId": 2,
  "targetComp": "post",
  "targetId": 3,
  "type": "author",
  "createdAt": "2024-03-28T13:28:59.175Z",
  "updatedAt": "2024-03-28T13:28:59.175Z"
}

AFAIK, no NoSQL database fully supports SQL, and only some offer support for transactions and joins. The idea here is to augment a relational database by adding capabilities for dynamic relationships.