Bulk updates/upserts ignore empty/blank fields

[MrDOS]

This seems to be a function of how the Bulk API handles CSV input. For example, if I have two Product2 records, each with a value in the “Description” field, and submit an upsert job with a blank value in that field:

Id,Name,ProductCode,Description
000000000000000000,Product A,1000,
000000000000000000,Product B,1001,

...the “Name” and “ProductCode” fields get updated, but the “Description” fields retain their previous values. However, if I hack together some XML-formatted batch input and add that to a job, it works as expected (clears the fields). So this definitely seems to be a CSV thing, not a Bulk API thing. (The SOAP API uses the fieldsToNull array to indicate sObject fields to be set to null, but there doesn't seem to be an equivalent of that field within the scope of the Bulk API.)

I'd like to featurize this with a command line flag for bulk jobs – depending on how the flag is set, Force CLI either sends the CSV data as-is (to ignore blank fields) or parses the CSV and sends it as XML (to handle blanks as blanks). If I were to implement this, do you have a preference for which behaviour would be the default with no flag set? I.e., should the default comply with (what is IMHO) the reasonable expectation of having blank values be treated as such, or should it be consistent with the way the utility has worked to date and ignore blanks?

Alternatively, I could avoid disguising a platform deficiency as a feature and instead let users specify whether their job input is CSV or XML. This would make the implementation more straightforward and perhaps less deceptive, but the benefit of CSV vs. XML would not be as obvious to the user (“XML input? Why would I want to use that?”).

[MrDOS]

...orrr I could read the documentation and notice that I can set CSV fields to “#N/A” to force them to be set to a blank value. Whoops! If there's any interest in submission of XML bulk jobs I'm still happy to do the work; otherwise, this issue can probably be closed.

[dcarroll]

Thanks for the post @MrDOS! I'm not sure xml is very popular these days so I think I would let that go until it is really needed.

[MrDOS]

Sounds good to me. Thanks for the speedy reply.