Poe’s law is real my friend.

score 1 · canonical

You want to replace a procedure that not only supports but highly encourages (basically forces) automation of a repetitive task with a process that is needlessly manual and costs money?

score 1 · canonical

Welp I blame reading it… I dunno, without coffee. Maybe too much coffee?

I knew it was a git clone in a dropbox folder, and somehow my brain read that line (even when I quoted it in my comment) as “a folder that had several folders of Make files”, and immediately I had visions of crazy people who know what Make is, but also put those Make files in Dropbox.

As the great man said, egg and my face, are in alignment.

score 1 · canonical

They then shared a Dropbox folder that had several folders of Markdown files.

This should have been the red flag. Not the .git directory or hooks in it.

score 1 · canonical

Apple Mail - both laptop and phone.

score 1 · canonical

I guess that’s great if your DB supports an array type, and supports it for ANY(), and the language bindings/driver have support for binding arrays natively.

score 1 · canonical

It’s tricky because we’re not used to write real SQL when using query builders

Speak for yourself. I quite frequently write ad-hoc queries (yes writing the queries, not asking a fucking robot in 8 iterations of increasingly verbose detail to write it for me). That works perfectly well because I know what I want at the time I’m writing the query.

That isn’t at all the same thing as using a query builder to allow the application to be able to filter on arbitrary columns, or complex value types, or have conditional conditions, or conditional columns returned, or any number of other dynamic aspects that are literally the reason for query builders to exist.

as soon as you learn how to do what you did with a builder with pure SQL, well it becomes trivial.

Ok fuck it, I’ll bite. What’s the “trivial, pure SQL” to take a variable length array/list/set/tuple/<whatever structure your language uses for a bunch of values>, and check if a column is equal to one of them.

i.e convert ['foo', 'bar', 'baz'] into ... WHERE col IN ('foo', 'bar', 'baz');.

score 1 · canonical

But I do know that passing in user-supplied data as separate parameters solves the problem for 90%.

Parameterisation does indeed solve the majority - the problem is that without the query builder, the developer inevitably has to resort to “building” at least some queries themselves - which is arguably more likely to result in issues again.

score 1 · canonical

To be fair, the vast majority of queries are not that dynamic in most programs.

I think we must work on very different types of program.

Give the history of the web and databases, removing the risk of SQLi by using a query builder in place of ad hoc dynamic query likely negates way more risks than the query builder introduces.

score 1 · canonical

Person.objects.filter(gender_concept_id=8507).order_by(‘year_of_birth’).values_list(‘person_id’, flat=True)[:100]

The main advantages I find this has are that filter is just expressed with keyword arguments

I don’t use Django (and vary little Python) so I had to look this up, but the “advantage” you’re referring to kind of goes down the toilet once you need anything other than the default “equals” operator, IMO.

This is the first example I found from the Django docs, for the filter method:

Entry.objects.filter(pub_date_year=2006)

Oh wait, no sorry it was actually this:

Entry.objects.filter(pub_date__year=2006)

Which kind of demonstrates my point. The two are not particularly distinctive visually, but they are obviously very different in terms of the SQL that is generated.

Using variadic arguments to define the column of a predicate is interesting, but the part where you chain together a bunch of double underscores and append them to the column name, honestly sounds like the kind of weird shit Wordpress or some other early-2000’s PHP monstrosity would do (and I say that as someone who makes a significant amount of my income from PHP-related projects).

score 1 · canonical

The only thing that’s tricky is when you need dynamic queries

So what you’re saying is, it’s easy to not use a query builder, so long as you don’t need to do the exact thing query builders are designed to make easier and safer.

Who would have possibly guessed that?

score 1 · canonical