A developer needs to programmatically add a new, complex data object to the customer entity. This data should not be a simple EAV attribute and must not alter the core 'customer_entity' table. The dat

Question

Options

• ADirectly join the custom data table in all collection classes that load customer data.
• BAdd a new column to the 'customer_entity' table using a schema patch.
• CDefine an extension attribute in 'extension_attributes.xml' and use a plugin on the Customer
• DCreate a preference for the 'CustomerRepositoryInterface' and override the 'getById' method.

• A
  8% (3)
• B
  16% (6)
• C
  70% (26)
• D
  5% (2)

Explanation

Option C is correct because Magento's extension attributes system is purpose-built for exactly this scenario: attaching complex, structured data to core entities without modifying core tables or schema. You define the attribute in extension_attributes.xml, create a custom table via a db_schema.xml declarative schema patch, then use an after plugin on CustomerRepositoryInterface::getById() (and getList()) to load and hydrate the extension attribute - keeping your code decoupled and upgrade-safe.

Why the distractors fail:

• A - Joining directly in collection classes is brittle, non-standard, and breaks whenever Magento changes its collection internals; it also doesn't cover repository-based loads.
• B - Adding a column to customer_entity modifies a core table, creating upgrade conflicts and violating Magento's extensibility contract.
• D - Creating a preference (full class override) for CustomerRepositoryInterface is the most fragile approach: only one preference can exist at a time, so it causes conflicts with other extensions and is explicitly discouraged in favor of plugins.

Memory tip: Think of the rule "Plugins over Preferences, Extension Attributes over Core Table Columns." Whenever you need to add data to an existing entity, the pattern is always: xml declaration + custom table + after plugin on the repository.

No community discussion yet for this question.