Clojurians Log v2

Technically to generate the following SQL:

SELECT geo_target_constant.id, geo_target_constant.name, geo_target_constant.target_type, geo_target_constant.country_code, geo_target_constant.canonical_name, geo_target_constant.status FROM geo_target_constant WHERE geo_target_constant.name LIKE 'Hungary%' AND geo_target_constant.country_code = 'HU'

SELECT geo_target_constant.id, geo_target_constant.name, geo_target_constant.target_type, geo_target_constant.country_code, geo_target_constant.canonical_name, geo_target_constant.status FROM geo_target_constant WHERE (geo_target_constant.name LIKE 'Hungary%') AND (geo_target_constant.country_code = 'HU')

I tried to play with the dialects, but that did not help

So Google Ads does not support compound queries where you would need parens to override precedence? Can you provide a link to the docs for this?

They don’t support complex queries they don’t even support OR conditions according to the docs: https://developers.google.com/google-ads/api/docs/query/structure#where

I did a string hackity-hack, which works now, but I wanted ask, since technically parens aren’t required AFAIK for “flat” where conditions

Create a GH issue and I'll give it some thought. It's all baked into the operator formatting right now and there's no way to override the parens. You can add nesting but not take it away.

Yes, I saw the functionality for the nesting and adding extra wrapping, but not the opposite

Creating a ticket now, thank you!

But before, I started to sponsor you 🙂

It is a long time overdue

https://github.com/seancorfield/honeysql/issues/574

Thank you! On both counts.

Thank you for the great libraries and all your efforts

The production of ( .. ) around sub-expressions is baked into a lot of the formatting via a :nested option that is passed down the tree so inventing a way to ignore that in some situations will be a bit tricky... but I may be able to do something fairly localized to allow the limited Google Ads case(s) maybe...

That would be great! Don’t stress too much about it, but maybe keep that in back of your mind when you doing some refactoring around the functionality.

What I do know is super ugly but works, I am using (format data {:inline true}) and then doing string manipulations to remove the wrappings.