true, but having it look like a component might get annoying. since this is likely to stay at the top, having an island of non components between two components might make it hard to see where functions start and end. and if this isn’t used directly inside a component it’ll just look dumb and inefficient (this also looks like it’ll take way more to edit once you change something)
I think I agree with you both. I’m not a Node developer; could you keep your SQL objects/components in a separate file so that they don’t clutter up other logic?
I was disgusted by the XML at first, but it’s a readable query returning a sane JSON object.
Meanwhile, I’m mantaining Java code where the SQL is a perfectly square wall of text, and some insane mofo decided the way to read the resulting list of Object[] 🤮 is getting each column by index… so I’d switch to SQXMLL in a heartbeat.
Remember, XML was actually designed for use cases like this, that’s why it came with XPath and XSLT, which let you make it executable in a sense by performing arbitrary transformations on an XML tree.
Back in the day, at my first coding job, we had an entire program that had a massive data model encoded in XML, and we used a bunch of XSL to programmatically convert that into Java objects, SQL queries, and HTML forms. Actually worked fairly well, except of course that XSL was an awful language to do that all in.
React simply figured out how to use JavaScript as the transformation language instead.
I’d like you to think for a moment about CTEs, the HAVING clause, window functions and every other funky and useful thing you can do in SQL … Now just think, do you think that this syntax supports all those correctly?
if you don't believe that adding more structure to the absolute maniacal catastrophe that is sql is a good thing then i'm going to start to have doubts about your authenticity as a human being
SQL is incredibly structured. It’s also a very good language, and developers need to stop piling on junk on top of it and producing terrible queries. Learn the damn language. It’s not that hard
If you think this is more structured than traditional SQL, I really disagree. Is this a select * query, it’s ambiguous. Also what table is being queried here there’s no from or other table identifier.
it was written to be a language that anybody could read or write as well as english, which just like every other time that's been tried, results in a language that's exactly as anal about grammar as C or Python except now it's impossible to remember what that structure is because adding anything to the language to make that easier is forbidden
when you write a language where its designers were so keen for it to remain human readable that they made deleting all rows in a table the default action, i don't think "well structured" can be used to describe it
having is less annoying way of not doing needless/bug-prone repetition. if you select someCalculatedValue(someInput) as lol you can add having lol > 42 in mysql, whereas without (ie in pgsql) you’d need to do where someCalculatedValue(someInput) > 42, and make sure changes to that call stay in sync despite how far apart they are in a complex sql statement.
Postgres has the having clause. If it didn’t, that wouldn’t work, as you can’t use aggregates in a where. If you have to make do without having, for some reason, you can use a subquery, something like select * from (select someCalculatedValue(someInput) as lol) as stuff where lol > 42, which is very verbose, but doesn’t cause the sync problem.
Also, I don’t think they were saying the capability having gives is bad, but that a new query language should be designed such that you get that capability without it.
Because you never learned SQL properly, from the sound of it.
You might be right, though, to be fair, I also keep forgetting syntax of stuff when I don’t use it very often (read SQL (._.`))
Also, ORMa produce trash queries and are never expressive enough.
I meant to say that I would like the raw SQL syntax to be more similar to other programming languages to avoid needing to switch between thinking about different flows of logic
No. The arrow function in where eliminates any possibility of using indexes. And how do you propose to deal with logical expressions without resorting to shit like .orWhereNot() and callback hell? And, most importantly, what about joins?
Not only is this really gross, it’s also straight up wrong. It’s missing a from clause, and it makes no sense for a where clause to be nested under the select. The select list selects columns from rows that have already been filtered by the where clause. Same for the limit.
Also just gonna go ahead and assume the JSX parser will happily allow SQL injection attacks…
Add comment