These sqlc-style libraries are a great solution to the problem of “make running a query as easy as calling a function”, but I’ve always thought SQL’s lack of composability is a more interesting problem that I haven’t seen addressed (the problems with views are well documented).
This is interesting! A field being nullable because it's legitimately optional in the domain model is one thing, but for new fields which shouldn't be nullable in the domain model, unless you can pick a reasonable identity value, you need a concept of absence that's different from null. Luckily the intersection of "non-nullable fields" and "fields with no reasonable identity value" and "fields which didnt exist in v1 of the domain model" is normally pretty small, but it's painful when it happens.
This reminds me of frozen/nonfrozen enums in Swift. You can do exhaustive case analysis on frozen enums, but case analysis on nonfrozen enums requires adding an `@unknown default` case.
Rails definitely seems optimized for creating code, but how is it at maintaining code? I've never used it, but it seems like Ruby's dynamic types would make it really challenging to do large refactors. What techniques do rails developers use?
> with functions named by their normalized hash contents, and referred to anywhere by that, but I can't seem to remember what it's called right now. Something like "Universe" I think?
Given that the literal founder of Flutter is in this thread using this introduction multiple times, it’s kinda hard to give you the benefit of the doubt that you honestly just meant “a founder using Flutter”.
> Redundant conditions are nice because they require no changes to the database [...] This makes them useful for queries that are only sometimes run or where indexes can't be easily added to the main conditions
but where possible I typically prefer adding an index on the expression that the query is using (if your database supports it) since it expresses your intent more clearly. A redundant condition is more likely to get "optimized away" by other developers or changes in the query planner.
I think the tone of this page is frustration that this page needs to exist. I think if I had to constantly deal with stuff like this I'd be pretty frustrated too:
> CVS-2019-19317 is an excellent example of a bogus CVE. This CVE describes a bug in an unreleased development version of SQLite. We were working on the new generated columns feature of SQLite, and a third-party hacker found an error in the code under active development, and then wrote a CVE against it. The error was fixed before the problem was ever released, and yet still there is this CVE sitting out there, unresolved, and as far as I can tell unresolveable.
Lot's of great related discussion from drh in this[0] sqlite forum thread.
I agree with your general point that "it's very hard to write safe C code", and
> people keep finding use-after-free bugs in sqlite3
is true, but
> that allow attackers to escalate the memory corruption into arbitrary code execution... bugs that have affected major projects, including iCloud and Chrome; here are a handful: there are lots more even from just the past year :/