Return count when row_count is selected

[colemanw]

When the api is selecting only row_count it should return the count, otherwise the output looks like an empty array

[colemanw]

I haven't tested this, I'm not familiar with the cv build process, but in theory this should make a command like this actually return something useful:

cv api4 Contact.get +s row_count

[totten]

I don't see how this part is relevant. Note that the result-code is important for handling errors in bash scripts. Returning 0 signals normal/successful exit. Errors should return non-zero. (Some tools go all-out and define various numeric-error-codes for different conditions. That's a bit of PITA here, which is why it merely returns 1.)

Some examples:

set -e
cd path/to/my/ext
git pull
cv upgrade:db
cd ..

set -e
cv api4 Contact.get +s display_name --out=list | while read NAME; do
   echo "Say hello to $NAME for me" 
done

cv flush && cv ext:list -R

In the first two cases, set -e means "If any command fails, stop execution and report the problem". If the third case, the && means "If left-command succeeds, then run right-command." They all rely on the exit-code.

[colemanw]

It's just cleanup. This function looks to have been copy/pasted from the api3 function. Api3 returns an is_error key. Apiv4 does not.

[totten]

Aah, interesting, so you can select the row_count even though it's not actually a field in the result. This feels weird.... but OK, it appears to work w/AJAX. The AJAX-bindings wrap all results in an extra layer of JSON ({values: ..., count: ...}).

Of course, the patch above works if you select only the row_count. If you want to get data as well as row_count, then one needs to be more like the AJAX-bindings. I guess one could port the AJAX technique -- and for compatibility purposes, treat it as a flag, e.g.

cv api4 Contact.get +s display_name,row_count --wrap

{
  "count": 123,
  "values": [
    {first},
    {second}
  ]
}

or like:

cv api4 Contact.get +s row_count --header

{"count": 123}
[
  {first},
  {second}
]

FWIW, even with the wrapping, there's still a problem with chaining. You can see this in AJAX calls:

I guess a couple questions:

• Looking forward -- Are there more header/wrapper fields that we should expect?
• Looking forward -- Do you expect some kind change/fix for the chaining issue?

If the answer is "No" on both fronts, then I'd be OK with this kind of special case. Otherwise, it's probably better to make the serialization formats more aligned.