preseinger

8 ms·

31.
by preseinger 3y ago
good lord man, the condescension is so thick and rich, it's like i'm reading an eclair, and the eclair is insulting me based on its own misunderstanding of the topic of conversation powerful stuff
32.
by preseinger 3y ago
i'm not sure we're talking about the same thing
33.
by preseinger 3y ago
nobody would use victoria metrics in earnest, i hope!
34.
by preseinger 3y ago
it doesn't! whatever code you put into the stored proc you can equally well put into a query, and the round-trip costs would be equivalent a stored proc is just a query saved on the db server, nothing more if you destructure a stored p
35.
by preseinger 3y ago
node A is connected to nodes B, C, D, E, F the A->B link is under DDoS or whatever and delivers packets with 10s latency the A->C link is faulty and has 50% packet loss the A->{D,E,F} links are perfectly healthy node B has one view
36.
by preseinger 3y ago
this doesn't magically fix the problem node clocks are unreliable by definition, it's a fundamental invariant of distributed systems
37.
by preseinger 3y ago
i'm running out of ways to say that a CRUD endpoint should not have dynamism in the sense that you mean /users/:id should map to 1 endpoint that's parameterized on userid /search?userid=:userid&tag=:tag should m
38.
by preseinger 3y ago
you can do that equally well in a stored procedure and a single query like, you can write a query which does all of these transforms in sequence, and returns the final result set the data that goes between client and server is only that fin
39.
by preseinger 3y ago
no? creating a query string that's parameterized on input usually means you model those input parameters as `?` or `$1` or whatever, and provide them explicitly as part of the query nobody is doing printfs of values
40.
by preseinger 3y ago
"reliable ordering" usually implies a specific and well-defined order, without concurrent events :)
41.
by preseinger 3y ago
kind of? not really? ordering is a logical property which can be informed by physical timestamps, but those timestamps aren't accurately described as "the basis" of that ordering
42.
by preseinger 3y ago
why would it take you two weeks to write 10 SQL simple queries?
43.
by preseinger 3y ago
huh? a single request returns a single result set to the client, whether it's a stored procedure or a direct query and any stored procedure can be equivalently expressed as a direct query, right?
44.
by preseinger 3y ago
> How do you share the "fetching posts" bit of SQL between those three different (parameterized) queries?) your application has a fetch posts method, that method takes input including (optional) author(s), tag(s), etc., it buil
45.
by preseinger 3y ago
i'm not sure what you're thinking about when you say "multiple related things" every "view" on your DB should be modeled as a separate function every possible "thing" that's input to a function w
46.
by preseinger 3y ago
huh? when your app queries the db, the query is not composed from several pieces, it is well-defined in the relevant method fn search(q string) -> result return db.query(`SELECT id, text FROM table WHERE text LIKE $1;`, q)
47.
by preseinger 3y ago
it's not like stored procedures are inherently faster than normal queries, right? as long as you're not doing anything dumb like connection-per-request, query caching should work the same
48.
by preseinger 3y ago
sure, sometimes, rarely -- these are exceptions, not rules in general, it should not be possible for user input to produce arbitrarily complex queries against your database each input element in an HTML form should map to a well-defined par
49.
by preseinger 3y ago
you definitely cannot rely on clocks to determine (reliable) ordering across machines truetime doesn't provide precise timestamps, each timestamp has a "drift" window timestamps within the same window have no well-defined ord
50.
by preseinger 3y ago
usual problem is when you try to model logical causality (a before b) with physical time (a.timestamp < b.timestamp) logical causality does not represent poor engineering practice :)
51.
by preseinger 3y ago
bare metal doesn't solve this problem, clock synchronization works until it doesn't ntp can fail, chrony can fail, system clocks can always drift undetectably you can treat the system clock as an optimistic guess at the time, but
52.
by preseinger 3y ago
usually, every interaction with your database is its own unique code path and query it's pretty rare for queries to be dynamically composed from arbitrary sub-queries if this is a problem you need to solve then ORMs certainly make more
53.
by preseinger 3y ago
an application (client) should be free to query a database (server) directly a stored procedure is an implicit dependency between client and server, fine as an optimization, but definitely not what you want to do by default
54.
by preseinger 3y ago
yep while they have different sets of pros and cons, neither is generally preferable to the other, they both get the job done with basically the same cost
55.
by preseinger 3y ago
ah, sorry, i misinterpreted what you meant -- obviously, yes, you're correct i thought you meant state that is created from a call stack and persists after that call stack returns -- which is something else
56.
by preseinger 3y ago
hopefully not it's certainly not a given
57.
by preseinger 3y ago
lol
58.
by preseinger 3y ago
logs always go to stdout/stderr hopefully!
59.
by preseinger 3y ago
you're complaining that the nomenclature for packages is not differentiated in a way that allows user code to have variable names with the same name as package names you can still allow this, of course, by aliasing the package import b
60.
by preseinger 3y ago
how? specifically?

More ›