Open mrsinham opened 9 years ago
I would rather handle this by adding support for the the missing fields. I presume you have code to handle the fields outside the library.
Well that is the problem, no I don't. I receive them but I don't need them, the implemeted fields are enough for me. I understand the logic to be « blocking » in order to force to implement as many fields as we can, but this is very blocking for a production environment.
Let's imagine Google adds a small change to the api in emergency (outside of the main release, but that impacts the return (not the request)), the library will return an error even if the asked operation succeeded. If the application (the code above the lib) code detects an error, it can understand that it is an update issue and misbehave.
Another problem for me is that when I'm just updating bids (well ie others services/languages/components/companies are adding, setting criterions, adgroup_id ) and because they add a parameter not handled on the library, I missbehave in return.
The logic is not IMHO safe as it should be. Perhaps handling the unknown fields differently (logging ? parts of the response ?) ?
This constants aims to deactivate strict attitude if the library encounters a fields that is not managed by it. Because I'm operating on many type of google adwords entities, sometimes the library gives me an error only because it doesn't recognize a field that is not managed (but that have no impacts on work). It adds the UnknowError type too.