CiviCRM Community Forums (archive)

Hi,

We have quite a few api GET requests call the DAO find function. I'm wondering if the rule should be to call the BAO retrieve function (if_exists). It would seem we should move up the stack where possible? In this example it would return 'is_current_member' which would seem to be a bonus


    /**
     * Takes a bunch of params that are needed to match certain criteria and
     * retrieves the relevant objects. We'll tweak this function to be more
     * full featured over a period of time. This is the inverse function of
     * create.  It also stores all the retrieved values in the default array
     *
     * @param array $params   (reference ) an assoc array of name/value pairs
     * @param array $defaults (reference ) an assoc array to hold the name / value pairs
     *                        in a hierarchical manner
     * @param array $ids      (reference) the array that holds all the db ids
     *
     * @return object CRM_Member_BAO_Membership object
     * @access public
     * @static
     */
    static function retrieve( &$params, &$defaults )

@civicrew

Why is the retrieve a different name than find?

Ie. if it's the same but better, should override the DAO::find function instead of defining a new one.

If it helps can easily create a function that returns the BAO of an entity, like I did for the DAO.

So, should we assume that api should use retrieve if it exists for a given entity?

I copied our standard boiler plate code from tag_get to pledge_payment_get - it doesn't work.

Pledge payment has a few unique fields but you can't pass unique fields to 'find' functions and the bit of code that massages $params down to the unique fields drops the non unique params

I think that pledge_payment is a good choice for us to improve our get function on as it has unique fields and since it has never worked (new) no-one is relying on it

So, I left in the failing test - testGetSinglePledgePayment until we can decide how our get with unique fields would ideally look