Bug #6269
Dealing with big quantities (100'000+)
| Status: | New | Start date: | 2010-01-28 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | Xavier Perseguers | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| Votes: | 0 |
Description
Thank you very much for this useful extension. It allowed us to deal with complex distribution formulas, grouping categories with AND and OR...
However, I noticed that in the current setup, the distribution is calculated when the send button is pressed, and the list of uids of fe_users or tt_addresses are stored as serialized array in a field that is a medium text, which means that it should be able to accomodate about 100'000 records, but not much more.
It would be better if the distribution was calculated by the cron script itself, in the class.dmailer.php, like is currently done for tt_address or fe_user native requests (The function to extend is function dmailer_masssend_list($query_info, $mid)
Olivier
History
Updated by Xavier Perseguers almost 3 years ago
Hi,
I did not forget about this feature but did not have time yet to work on it.
I'm just wondering whether this feature would not have a possible side effect in weird situations:
- You prepare a list of +100K addresses
- You send the newsletter
- DM uses chunks of around 50 persons
- The list is recomputated each time the next chunk is needed
- New addresses are added or existing are removed
=> some addresses may probably be skipped by DM as the position in the list does not reflect the reality.
What do you think?
Updated by Xavier Perseguers almost 2 years ago
- Tracker changed from Feature to Bug
Actually this is can be seen as a bug as dealing with big lists seems to require a big amount of RAM to be able to show the list of recipient lists (I had to allow 256 MB instead of 192 MB for two lists, each having ca 2000 entries).
NOTE: the underlying lists are generated using a domain model similar to an Extbase-based one.