Add missing indexes on emailsubscription table

[Prestaplugins]

Questions	Answers
Description?	The emailsubscription table only had a primary key on id, while the module repeatedly looks up guests by email / id_shop and lists active subscribers by active / id_shop. This PR adds KEY email_shop (email, id_shop) and KEY active_shop (active, id_shop) to the install schema, plus an upgrade script (upgrade/upgrade-3.0.1.php) for existing shops. Module version in PHP / config.xml is intentionally left at 3.0.0 — PrestaShop decides the release version.
Type?	improvement
BC breaks?	no
Deprecations?	no
Fixed ticket?	Fixes #140
How to test?	Fresh install: install the module from this branch and run SHOW INDEX FROM <prefix>emailsubscription — expect PRIMARY, email_shop, active_shop. Upgrade: with the module already at 3.0.0, run the upgrade script path (or temporarily set $this->version to 3.0.1 locally only to trigger the upgrade), then confirm the two indexes appear. Functional smoke: subscribe / unsubscribe a guest email, open BO subscribers list / export, verify FO + BO still work.
Sponsor company	Prestaplugins

[ps-jarvis]

Hello @Prestaplugins!

This is your first pull request on ps_emailsubscription repository of the PrestaShop project.

Thank you, and welcome to this Open Source community!

[Prestaplugins]

Correction: module version is no longer bumped in PHP / config.xml (stays at 3.0.0).

PrestaShop decides the published module version. The upgrade script upgrade/upgrade-3.0.1.php is kept so shops can pick up the new indexes when that next version is released. Install schema indexes are unchanged.

[Codencode]

I checked the queries against emailsubscription and also tested the proposed indexes with about 50k rows.

The email index looks clearly useful: an email + id_shop lookup went from a full table scan (~50k rows) to using the email index with an estimate of 1 row.

I'm less sure about (id_shop, id_lang), though. Looking at the module, id_lang does not seem to be used as a filter on emailsubscription; it is only used for the JOIN with lang.

For example, the subscribers query filters on:

WHERE e.active = 1

and, depending on the shop context, may additionally filter on:

AND e.id_shop = ...

With the proposed (id_shop, id_lang) index, EXPLAIN used only the id_shop prefix:

key: id_shop_lang
key_len: 4
ref: const
rows: ~18000
Extra: Using where

I also tested (active, id_shop).

With both filters:

key: test_active_shop
key_len: 5
ref: const,const
rows: 5000

and with only active = 1:

key: test_active_shop
key_len: 1
ref: const
rows: ~24900

So (active, id_shop) appears to match the actual queries more closely and can also still be used when there is no id_shop condition.

Would it make sense to reconsider (id_shop, id_lang) and use an index involving active instead?

[Prestaplugins]

Hi @Codencode, thanks for the review and the EXPLAIN tests — we agree with your analysis.

id_lang is only used in the JOIN with lang, not as a filter on emailsubscription, so (id_shop, id_lang) was not the right choice. We updated the PR accordingly:

• replaced (id_shop, id_lang) with (active, id_shop) (KEY active_shop) for the subscribers / export queries
• refined the email lookup index to (email, id_shop) (KEY email_shop), which still works via the leftmost prefix when there is no shop filter (e.g. all-shops email checks)

Install schema + upgrade/upgrade-3.0.1.php and the PR description are aligned with this.

[Codencode]

@Hlavtox can you also check?