I think new Selector is great because it provides unified interface for 'Get' operation over many services.
Because it is used by many services, it cannot be more strongly typed. I like the idea from TargetingIdeaSelector which uses AttributeType array as input and Type_AttributeMapEntry array (actually a dictionary, transformed to array) as output. This provides more secure, strongly typed selecting of desired fields (attributes), but negative side is that it is very verbose. Sandbox works great for me, but it would be event better if same limits would be imposed as in production environment, so I don't have different error handling for Sandbox and Production environments. For example, TargetingIdeaService expected different max. number of keywords in Sandbox and Production. On Wed, May 18, 2011 at 6:14 PM, Pete Lavetsky (AdWords API Guru) < pete.lavet...@gmail.com> wrote: > I deployed on v201101 last night and have a couple thoughts. > > Like most people I don't use every single service, but I use the bulk > of them. The largest migration effort I had was dealing with the > generic Selector. The ability to set the Predicates for filtering is > very, very cool and opens the door for more efficient coding. > However, to mandate setting the return fields doesn't provide any > value to me, and will only lead to more troubleshooting and code > maintenance in the future. > > The largest issue I have with the change is there's no one single > document that states what the field values are. Unless I missed a > resource, I have to go through the API object docs one by one and look > at what is "selectable". This is a hassle and leads to buggy code. > Could there at least be static final variables in the object model we > could code off rather than copy & pasting from the docs? > > I write wrappers around the Google services, and for my wrappers I'm > requesting the same fields for every service call I make, regardless > of what values I'm going to work with. I haven't seen a document > stating "If you only request Id and Status your object will return in > 5ms where as if you request a fully attributed object your return call > will take 100ms". I don't see any value to not requesting the same > fields every time and I've coded that way, reusing the same static > string array of fields in all relative calls to cut down on bugs. > > To go along with the lack of aggregated selectable documentation, if I > migrate to the next version of the API and one of those objects is no > longer is selectable, I'll get Selector errors and have to modify > code. I could either go through the ~50 documents one by one and > double check what I'm currently setting for fields, or I could > release, make a call, get Selector error, iterate ... a hassle either > way > > Cross client reporting: where's it at? Lots of stuff is sunsetting in > July, is that date going to be revised? I know it's annoying to give > the same vague answer to the 10% of group postings that deal with this > but we should be given a more solid answer for both questions. > > Are more campaign targets going to move to settings like > NetworkSetting? I see that as an improvement. > > And last, the Sandbox continues to suck. It's not worth my time to > get everything setup through it. It's not a reasonable mirrored > environment of the live data and as has been discovered through a few > postings to this group, even the services in the Sandbox don't always > mirror what we're supposed to be coding against in the live > environment. At the very least I would like a couple convenience > methods to: wipeSandboxAccount, populateSandboxAccountFromLiveAccount > so I can more easily test my code in a development environment > > I focused on the negatives, but the truth is most of the API continues > to kick ass and is fun to work with. > > Pete > > -- > =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ > Also find us on our blog and discussion group: > http://adwordsapi.blogspot.com > http://groups.google.com/group/adwords-api > =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ > > You received this message because you are subscribed to the Google > Groups "AdWords API Forum" group. > To post to this group, send email to adwords-api@googlegroups.com > To unsubscribe from this group, send email to > adwords-api+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/adwords-api?hl=en > -- AdWords API in C# / VB.NET <http://www.gemboxsoftware.com/Ppc/Overview.htm>- GemBox.Ppc component -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
