preseinger

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

i'm not sure we're talking about the same thing

nobody would use victoria metrics in earnest, i hope!

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 proc to multiple individual queries, ok, sure, but who would do that?

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 of A's skew which is pretty bad, node C has a different view which is also pretty bad for different reasons, and nodes D E and F have a totally different view which is basically perfect

you literally cannot "detect skew" in a way that's reliable and actionable

issues are not a function of the node, they're a function of everything between the node and the observer, and are different for each observer

even if clocks were perfectly accurate, there is no such thing as a single consistent time across a distributed system. two events arriving at two nodes at precisely the same moment require some amount of time to be communicated to other nodes in the system, that time is a function of the speed of light, the "light cone" defines a physical limit to the propagation of information

this doesn't magically fix the problem

node clocks are unreliable by definition, it's a fundamental invariant of distributed systems

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 map to 1 endpoint that's parameterized on userid and tag(s)

endpoints should be simple to write

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 final result set, it's not like the client receives each intermediate step's results and sends them back again?

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

"reliable ordering" usually implies a specific and well-defined order, without concurrent events :)

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

why would it take you two weeks to write 10 SQL simple queries?

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?

> 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 builds a query that includes WHERE clauses for every provided parameter

the code that converts an author to a WHERE clause can be a function, the point is it outputs a string, or something that is input to a builder and results in a string

i'm not sure what a "fetching posts bit of SQL" is, a query selects specific rows, qualified by where clauses that filter the result set, joins that modify it, etc.

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 which queries the database should be transformed into a part of the query string by that function

> The DB accepts a structured query, not a string. It might be represented as a string on the wire, but if that was what mattered then we'd use byte arrays for all our variables since everything's a byte array at runtime.

...no

the API literally receives a string and passes it directly to the DB's query parser

if the DB accepted structured queries, then the API would rely on something like protobuf to parse raw bytes to native types -- it doesn't

like `echo SELECT * FROM whatever; | psql` does not parse the `SELECT * FROM whatever;` string to a structured type, it sends the string directly to the database

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)

this is a single query, not multiple

the db accepts a string and parses it to an AST, it does not accept a typed value

this means the interface is the string

unbalanced parens and whatever other invalid syntax is obviously caught by tests

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

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 parameter of a SQL query builder, like, you shouldn't be dynamically composing sub-queries based on the value of a text field, the value should add a where or join or whatever other clause to the single well-defined query

sometimes this isn't possible but these should be super rare exceptions

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 order, applications have to take this into account when doing e.g. distributed transactions

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 :)

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 it's never a reliable way to order anything across different machines

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 sense, but even in this case I find query builders to be more effective

the interface between the application and the DB is actually a string! it's not an abstract data type, it doesn't benefit from being modeled by types

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

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

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

hopefully not

it's certainly not a given

lol

logs always go to stdout/stderr

hopefully!

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

but needing to do this is "terrible"

is that correct?

how? specifically?