Honestly more readable than a lot of SQL I’ve read. It even has hierarchical grouping.
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.
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?
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?
Ah yes. That’s what the kids call “sqlx” right?
NGL, if it has real time code completion and compile time SQL checks, this is fine.
I actually like this. This would allow reuse of all the infrastructure we have around XML. No more SQL injection and dealing with query parameters? Sign me up!
Better than parameterized queries. Yes, we have stuff like query("INSERT INTO table(status, name) VALUES ($1, $2);").bind(ent.status).bind(ent.name).execute..., but that’s kind of awful isn’t it?
With XML queries, we could use any of the XML libraries we have to create and manipulate XML queries without risking ‘XML injection’. e.g we could convert ordinary structs/classes into column values automatically without having to use any ORM.
I mean, that’s just a bad library interface. With a halfway decent interface, you can do something like
query('insert into foo (status, name) values (:status, :name)', ent)
No orm required. With tagged templates in JS, you can do
q`insert into foo (status, name) values (${ent.status}, ${ent.name})`
Even wrap it in a function with destructuring to get rid of ent:
const addFoo = (q, {status, name}) =>
q`insert into foo (status, name) values (${status}, ${name})`
Typescript can add type safety on top of that, of course. And there’s the option to prepare a query once and execute it multiple times.
Honestly, the idea of manipulating XML queries, if you mean anything more fancy than the equivalent of parameter injection, sounds over-complicated, but I’d love to see a more concrete example of what you mean by that.
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…
