Expected Operation or Bug?

Jeff's out this week, so I'll ping him when he gets back. I'm pretty sure that this is by design on the update method, but I can see your point on the createOrUpdate.

JeffMills :

It is by design because sometimes setting a field blank might be desired.

Soo Jeff,

Your suggestion would be then, if a field is blank to not process that field? I can see where it would be desired, and where it would not.

It would be nice if you could designate in the API though -- much like surveys work -- where you can say whether an record should be

• update no matter what,

• updated only if an improvement,

• accept but do not update,

• or send back an error to require user to login

Michael :

It seems to me that, if you're already writting code to use the update API, including a clause in the field collection routine that excludes a blank field you don't want to overwrite a potentially populated field in Convio would be a fairly simple matter. You probably have a better idea what you do and don't want to make blank. Besides, what happens when you want SOME fields to be blanked and other's not? For example, what if you're writting an internal-use webapp for your donor relations folks or something? There might be valid reasons why they want to erase invalid data in some cases, but have no updated data for other fields. You could use a checkbox or something to designate the behavior Adrian suggested on a field by field basis based on the data rather than create an API requirement that becomes a blanket for all aspects of a given data app.

That said, there isn't any reason why building into the API is a bad idea, provided BOTH things are possible, having both flexibility and convenience is a good thing!

While it is true that it is fairly straightforward (to check for the existence of a field's value or not), it does however increase the complexity of the code you have to write -- especially if you still would like your code to remain flexible.

That being said, there are probably other good reasons to do field by field collection anyway depending on the form (validating the values in other ways, for instance).

But in any case, having the a API call with the behavior I suggested (a switch for how an update is processed) would still allow for that kind of checking and processing.