CiviCRM Community Forums (archive)

FYI: we are still different from V2 (the results aren't under a "values" key but directly into the returned array) :

http://api.crm/civicrm/ajax/rest?fnName=civicrm/contact/get&json=1&debug=1&return_contact_type=1&return_display_name=1&version=2

{
"0":{
"contact_id":"1",
"contact_type":"Individual",
"display_name":"Xavier Dutoit"
},
"1":{
"contact_id":"2",
"contact_type":"Organization",
"display_name":"Tech To The People"
},
"2":{
"contact_id":"3",
"contact_type":"Organization",
"display_name":"toto"
},
"deprecated":"Please upgrade to API v3"
}

And just wrote something wrong: the key is an index, not the id of the contact (and now I remember why I really didn't like this format: that's both uglier than the normal array, not useful, and a pain to handle in js)

X+

Ah, weird that it's different between rest and api. Will run a bit more testing on a 3.3 install with a little bit less dummy data.

Anyway, v2 is:

$result = civicrm_contact_get( $params );
        $this->assertEquals( 2, count( $result[17] ) );
        $this->assertEquals( 17, $result[17]['contact_id'] );
        $this->assertEquals( 'Test', $result[17]['first_name'] );

But v3 is either (sequential)

$result = civicrm_contact_get( $params );
$result = $result[results];
        $this->assertEquals( 2, count( $result[0] ) );
        $this->assertEquals( 17, $result[0]['contact_id'] );
        $this->assertEquals( 'Test', $result[0]['first_name'] );

or (non sequential)

$result = civicrm_contact_get( $params );
$result = $result[results];
        $this->assertEquals( 2, count( $result[17] ) );
        $this->assertEquals( 17, $result[17]['contact_id'] );
        $this->assertEquals( 'Test', $result[17]['first_name'] );

While we are at it, the syntax for the param is probably a few lines of change of being able to handle:


  $params = array( 'contact_id'       => 17,
                         'return' => 'first_name,last_name',
                         'sort'              => 'first_name' );
and
  $params = array( 'contact_id'       => 17,
                         'return' => array ('first_name,last_name'),
                         'sort'              => 'first_name' );

on the top of uglier:
  $params = array( 'contact_id'       => 17,
                         'return_first_name' => true,
                         'return_last_name' => true,
                         'sort'              => 'first_name' );


(already changed the code for the REST, just put it at the right place, might already work actually).

I'm sure you just like changing things! I agree that it's nicer but as long as the original works I'm not going to change any tests around this one.

My point was that if the array result as on v3 is under a "values" and not directly under the result, we will have to change the test anyway,  no ?

My next question though - bearing in mind the known occasional memory leak is     $ufJoinDAO->free; best practice & if so where - in this case an empty won't be returned.

No idea.

Lobo, you have wrangled the DB object beast to have an opinion ?

Hi,

I just implemented the sequential for a couple of functions by adding &$params as an optional parameter for civicrm_create_contact and adding your clever bit of code in there. I think there are some potential down the track advantages of this:

1) I suspect that some functions may currently be altering the $params array & stripping non-BAO keys in which case the $params option would fail & we would pick this up

2) I think it's likely we might intro other formatting options later so passing params to the civicrm_create_success now will make it easier to do that later.



ALSO

I think that I STILL need to confirm what is agreed on the return params. My understanding is that create, get AND delete will all return in id indexed array of results (or sequential on the param)

At this stage delete & create only return one result but at some future point they might return more than one so returning

array('is_error' = 0,
         'version' = 1,
        'values'   =array(15=> array('id'=15)
       )

for a delete seems unweildly but has the advantage of being consistent with GET and is more future proof.
Some of the CREATE options return an array of values rather than just ID which I think is good. default for create & delete could be that 'is_sequential' is set?