Aijan

joined 4 months ago
MODERATOR OF
120
I Don't Trust My Own Code (lackofimagination.org)
[–] [email protected] 7 points 3 months ago

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.

[–] [email protected] 4 points 3 months ago

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.

[–] [email protected] 7 points 3 months ago (2 children)

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.

[–] [email protected] 3 points 4 months ago* (last edited 4 months ago) (1 children)

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.

[–] [email protected] 3 points 4 months ago* (last edited 4 months ago)

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.

[–] [email protected] 2 points 4 months ago

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.

[–] [email protected] 3 points 4 months ago (5 children)

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"
}
[–] [email protected] 3 points 4 months ago

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.

15
Beyond Foreign Keys (lackofimagination.org)
submitted 4 months ago* (last edited 4 months ago) by [email protected] to c/[email protected]
 

In a relational database, foreign keys are normally used to associate records stored in different tables, but wouldn’t it be nice to define relationships dynamically without having to add extra columns or tables? And while we’re at it, how about having sparse relationships by associating a record directly with any other record like “post X was last edited by user #123” or “post X was flagged for review by user #456” (who happens to be a moderator)?

[–] [email protected] 1 points 4 months ago

You're welcome.

[–] [email protected] 1 points 4 months ago (2 children)

Agreed, this article is old, but I think it does a good job of showing how similar Alpine and Vue are.

[–] [email protected] 1 points 4 months ago

That idea crossed my mind too. AFAIK, you can't really use SQL in graph databases, and that's a deal breaker for me.

 

Unlike most modern javascript frameworks, Alpine requires absolutely no build, you simply include the library and away you go, all features included. It’s also super lightweight. If you already know Vue, you basically know Alpine, making it perfect for Vue developers to turn to for projects where Vue is simply overkill and without the headache of learning something completely alien.

 

Tie-in is a relational data component library that lets you store and query records that can be related to any other record.

The relationships in a database are usually defined between columns across tables. In Tie-in, however, relationships can be defined between individual records. Relationships can also have types, so you can have multiple relationships between two records.

The ability to associate a record with any other record in any table opens up new possibilities that are hard to accomplish with conventional column-based relationships. In addition, since relationships are dynamic, no schema changes are necessary to define new relationships.

view more: next ›