I have been following the progress of this module since the start of drupal 7. For a long while I had my own implementation. Last time I had to implement a connection between drupal and mailchimp I decided to take a look at the status of this module and seeing how far was nicely implemented I just dropped my own implementation and enhanced it with a different way of adding the nodes to the content sections.
For this I needed to alter the scheme of the mailchimp campaign because I needed and id that was type serial(int autonumeric).
Basically I want to add fields to the mailchimp campaign entity and to be able to add fields I need an entity_id that is an integer.
When I saw that mailchimp was ready for Drupal 8, I went to dive into it and then I saw that the id of the mailchimp campaign is still the varchar id from the mailchimp id of a campaign. Since I have seen that the mailchimp campaign seems to not retrieve the mc_campaign_id as $entity->id(at least as far as I have seen till now) I was wondering... why not to just extend the baseFieldDefinitions from the parent so we can get the id as a serial and treat mc_campaign_id as just a field.
If you find that the request is something that can benefit the module and use this way the mailchimp campaign as a more drupal like entity... I don't mind doing the work and committing it. But I just wanted to see if the decision of having a varchar as the id of the entity was something that is architecture and cannot be changed.
Comments
Comment #2
e.escribano CreditAttribution: e.escribano commentedComment #3
samuel.mortenson@e.escribano This architecture is intentional and changing it at this point would require a data migration and API changes, which I don't think we could even do in a new major release. I don't think having a string ID should stop you from using the entity API in Drupal 8 however, as other content entities I've worked with use string IDs and function normally.