Honestly more readable than a lot of SQL I've read. It even has hierarchical grouping.
Programmer Humor
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
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.
React basically figured out how to make XML work.
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.
it's a readable query returning a sane JSON object.
No it's not. What table is the data supposed to be coming from..?
Check out JOOQ.
JOOQ made me realize that most ORMs suck
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)
It is so readable that you missed the fact it doesnโt have the FROM clause
Honestly not the worst thing Iโve seen.
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?
sql syntax doesn't support even itself correctly i fail to see your point
Probably no better or worse than any other ORM written in a more traditional language. Worst comes to worst, you can always escape to plain SQL.
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...
I like the format, though.
Booooo
I want to hate this. I really do. But the problem isโฆ I think I like it.
But how do I know if the WHERE clause is AND or OR?
Fair. The constraint nodes should probably exist under an And
or Or
node.
This needs a bit of work but it could be interesting
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
Me trying to remember on whose output data having
, count
, sum
, etc. work
Once you know functions you would have no reason to go back.
I propose we make SQL into this:
const MAX_AMOUNT = 42, MIN_BATCHES = 2
database
.from(table)
.where(
(amount) => amount < MAX_AMOUNT,
table.field3
)
.select(table.field1, table.field3)
.group_by(table.field1)
.having(
(id) => count(id) >MIN_BATCHES
table.field0
)
(Sorry for any glaring mistakes, I'm too lazy right now to know what I'm doing)
..and I bet I just reinvented the wheel, maybe some JavaScript ORM?
Because you never learned SQL properly, from the sound of it.
Also, ORMs produce trash queries and are never expressive enough.
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
ORMs produce good queries if you know what you do. Which requires proper knowledge of SQL, unfortunately.
most languages have some first or third party lib that implements a query builder
Thanks for the suggestion! It looks interesting, not quite what I expected looking at that file*, but that may very well be better
Edit: other examples seem a bit more similar to mine, cool!
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?
please kindly send all javascript into the sun and explode it
The most offensive thing here is the amount={5}
attribute. What is it? It's not XML.
It's JSX. It's used to embed markup into javascript
It's to embed Javascript into embedded markup in Javascript
still more readable than sqlalchemy exceptions
I haven't been this pissed off since LINQ started allowing syntax switches in random-ass places.
Of course not... where's the damn tag..?
Joins must be a pain in the ass with hooks
Sharepoint queries are written in something very similar ๐คข
I still have nightmares from the one time I had to use that.
got no clue abot sql. what is wrong and how is it supposed to look like?
this basically xml being made to look like SQL. It's gross and that's why it's funny
SQL is run on the server to communicate with a database. The screenshot is jsx, which is a front-end, UI templating language. Writing SQL this way is cursed
SQL is supposed to look like this: SELECT status, name FROM some_table LIMIT 5
Different language
I kind of like it. I can understand where it start and end.
Needs JSON embedded in the elements because JSON is best practice.