Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-03-26

Channels

#off-topic
<
2022-03-26
>
Nundrum14:03:42

To @denis.baudinot’s point, I've found that the core structure of a project can be surprisingly hard to find an identify. I recently read through the procps-ng codebase so I could put some similar functions in something I was writing, and it took me way too long to figure out that one of the key sections of it was setting up and then calling a function pointer. It was one tiny easy to miss line that was keeping me from understanding what was going on at first glance.

👍 1
dpsutton17:03:21

Qualifying session 1 in the books

bronsa23:03:24

what a trip it was

dpsutton01:03:59

yeah. that was an absolutely wild session

raspasov11:03:50

"Monaco at Monza speeds + Spa-style flat out sweeping corners" is a dangerous combination for sure.

dpsutton14:03:47

Yeah it leaves me a little confused. Grade 1 certification for tracks means really expensive modifications or just slap some concrete walls along the whole thing?

Martynas Maciulevičius17:03:15

I've read the criticism of the SQL and ... well... What should I do if I have my personal project with PostgreSQL but at work I have XTDB and there I have a collection document attribute (similar to psql array)... but the difference is that I can look up the document by the value in that collection. I know that I could make something similar in Postgresql if I'd use a table for this... but it's so bad... I'm frustrated. Because not only I'll need a table for this. But then it will also make the join. And every query that I'll have will need to be a join... oh noo

Martynas Maciulevičius17:03:37

So after a while when I didn't look at that code at all... All of this untested sql code... it's still code but I can't have tests for it... oh no.

p-himik18:03:29

What prevents you from using XTDB for your personal project as well? :) Also, you can look up rows by values within an array. But I don't quite recall whether any kind of index could be used for that.

Martynas Maciulevičius18:03:56

Psql array = full scan https://www.postgresql.org/docs/current/arrays.html And the docs say that it's a bad practice. And my project... well it's quite big and I can't reuse what I already have because well... I have psql queries... so I'm in a bad spot.

p-himik20:03:42

> Psql array = full scan Not sure that's correct: https://stackoverflow.com/a/29245753/564509 > it's quite big and I can't reuse what I already have because well... I have psql queries You can always migrate? Surely you have something like migratus or whatever to help you with that. You can unroll arrays if you want, and then hide all those joins behind a view. You can even create a view that rolls those values back into arrays to make migrations gradual.

isak17:03:36

In my opinion it is easy to create a usable layer over SQL for querying, but the crappy SQL data modification syntax is hard to abstract away, at least when things need to happen in multiple tables.

Martynas Maciulevičius17:03:37

I was designing a layer for this but didn't do any coding yet. But yes, I don't even know what would be the way to wrap multi-table writes... I don't think it's a good idea... it's probably too hard. Transactions... idk...

isak17:03:20

If I absolutely had to try, I might try going with something like this as the API: 

[{"type": "insert",
  "table": "Person"
  "values": {"email": ""},
  "as": "newUser"},
  {"type": "insert",
  "table": "Project"
  "values": {"title": "New Project", "manager_id": ["var", "newUser.id"]}}]

isak19:03:56

Yea that could probably be used