queryBuilder.for() dangerous footgun behavior

Which objection version are you using?

I'm using v2.x but confirmed issue also exists on v3.x.

What are you doing? What code are you running? What is happening? What are you expecting to happen instead? If you provide code examples (please do!), use the actual code you are running.

The queryBuilder.for() docs clearly explains:

This method can only be used in conjunction with the static relatedQuery method. See the relatedQuery documentation on how to use it.

# GOOD
var fooId = 1;

Model.relatedQuery().for(fooId);

IMO, it's still easy to accidentally use Model.query().for() (which is incorrect usage) and have it do nothing:

# BAD
Model.query().for(fooId); // .for() is silently ignored here, causing the SQL to fetch ALL rows

# VERY BAD
Model.query().for(fooId).patch({ x: 1 }); // .for() is silently ignored, causing the SQL to patch ALL rows (!)
Model.query().for(fooId).delete(); // .for() is silently ignored, causing the SQL to delete ALL rows (!)

This is not a bug, but I think it would be an ideal enhancement if we implemented throw new Error() for these dangerous scenarios (and I just accidentally patched my entire DB due to this! 😭). This would be similar behavior to the Error that Objection currently throws when calling instance.$setJson('this should be an obj').

• Could we add throw new Error() when executing the QueryBuilder that has an unused .for()? Or only implement .for() for QueryBuilders that were generated by Model.relatedQuery()?

• Here's a link to a reproduction-template.js gist that reproduces the situation

Start with the reproduction-template.js gist and compare Model.query().for() with Model.relatedQuery().for(). Read the queryBuilder.for() and relatedQuery documentation, then trace QueryBuilder execution to determine where unused .for() calls are handled. Done means the dangerous scenarios are covered by tests and no longer silently affect all rows.