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

e.escribano created an issue. See original summary.

e.escribano’s picture

Assigned: e.escribano » Unassigned
samuel.mortenson’s picture

Status: Needs work » Closed (won't fix)

@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.