Posted by Sid_M on June 30, 2009 at 8:01am
| Project: | Salesforce Suite |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Issue Summary
Since subsidiary modules may extend field maps in various ways, and may want to cascade deletes of field maps, the salesforce_api module should invoke a hook when it deletes a field map.
Based on a subsidiary module I am developing (and which I will submit as a patch soon), I propose adding hook_sf_fieldmap_deleted which takes the idea of the deleted field map as an argument.
Comments
#1
Hmmm, seems the I didn't attach the patch. Trying again.
#2
Can you enlighten me on what you mean by cascade? Where can I see more about the module you are working on? Do you plan to contribute to SF API module? Or as it's own Drupal.org contrib module?
The feature and patch seem fine, however the patch uses too much indentation; two space characters is standard. Also, it should be created from salesforce root directory.
#3
I found this at #507800: Check for existing duplicates on object-create
#4
Yes, the issue you reference is the one to which I was referring.
What I mean by cascading is this. A module, such as the one you found, may have its own data tables where it stores information about fieldmaps. In the case of my module, I'm storing the names of fields to use for a fieldmap's initial synching of an object (that's vague, but is explained in the other issue). So my module has a table where each row corresponds to a row in the fieldmaps table. If a fieldmap is deleted, it's good practice for me to delete any of my module's data which is related to the deleted fieldmap. That's what I mean by cascading: the delete starts with the original object (in this case a fieldmap), and cascades down to all related objects. The sf api handles cascading internally by deleting all object maps which relate to a deleted fieldmap. So I want a hook which notifies my module (and any other interested modules) when a fieldmap is deleted, along with the id of the deleted fieldmap. I hope that adequately clarifies. If not, please let me know what's unclear. Thanks.
#5
Thanks Sid. That makes sense. I think at least one other SF API maintainer needs to weigh in on this. I agree in principle, but I'm not sure this is the best method. Some minor style issues in #2 remain unaddressed.
#6
hook_sf_fieldmap_deletedseems reasonable to me,though i might rename it to
hook_sf_fieldmap_delete.Does it make sense to implement other hook_nodeapi-style CRUD hooks for fieldmaps as well? (In another issue of course)
Bevan, can you propose another method of implementing this?
#7
I agree that hook_fieldmap_delete() is better name than hook_fieldmap_deleted(). Mostly because it's more consistent with drupal's naming conventions.
Since #507800: Check for existing duplicates on object-create is probably going to be in SF API's package and maintained alongside SF API, it's okay for salesforce_api.module to be aware of sf_prematch.module and it's functionality. Also, I can't see a likely use case for any other module caring about this hook (Maybe I'm missing something?).
So it would be simpler and more efficient to do something like
<?phpif (module_exists('sf_prematch') {
// Call a function in sf_prematch.module...
}
?>
With this approach, that change should be in #507800: Check for existing duplicates on object-create's patch. What are the disadvantages of this approach?
#8
Bevan's point about efficiency is especially relevant since implementation of
hook_sf_fieldmap_deletein sf_prematch is a one-liner. I've rolled up sf_prematch into a side-by-side module of this package. Functionsalesforce_api_fieldmap_deletewill simply callsf_prematch_match_by_delete.see http://drupal.org/cvs?commit=332864
If there is further demand for this hook, please un-postpone this ticket and state your case.