There is an issue with the 'fields' field in the salesforce_field_map table being a reserved word in mysql 4.1. When using mysql 4.1 it renders creating a fieldmap impossible. This was first mentioned in:
#480020: Database table(s) not created
This is a pretty critical bug. Though mysql 4 is becoming increasingly uncommon, the drupal project claims that it is supported, thus I feel this module should support it as well. The quick fix in comment #5 in the above issue no longer applies. I needed this functionality immediately on a project, so wound up modifying the schema and plugging a couple workarounds in the salesforce_api_fieldmap_save and salesforce_api_fieldmap_load functions (patch attached). It's not pretty, and I'm not sure that reworking the schema is the correct final approach. I'm just throwing this out there in hopes of starting a discussion and working to a more permanent solution.
patch rolled on the 6.x-2.x-dev varsion of salesforce_api from within the salesforce folder
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | salesforce_map_field.patch | 1.46 KB | rho_ |
| salesforce_map_field.patch | 1.46 KB | rho_ |
Comments
Comment #1
rho_ commentedOops did that patch backward, sorry folks.
*friggin embarrassed*
Comment #2
kmontyComment #3
aaronbaumanchanges also need to be made in sf_user, sf_contrib, sf_node, sf_prematch.
Additionally, in salesforce_api: salesforce.class.inc, salesforce_api.admin.inc, and salesforce_api.module need to be updated throughout to reflect the new schema.
Finally, fieldmaps are objects now, so the change should use object notation instead of array notation.
Comment #4
EvanDonovan commentedShould this patch still be considered, or should MySQL 4.1 simply be unsupported?
I think in 7.x, at least, MySQL 4.1 should be unsupported, since I don't think Drupal 7 supports it.
Comment #5
kostajh commented