Stumbled on this nice module when looking for a solution for sent email archival. However, since we generate a lot of outgoing email, we are concerned about:
- Storing too much data on our main DB has not the same storage requirements (latency/cost, backup, etc.)
- Imposing too much load on the DB server (transactions/replication)
- Not being the ideal storage for later search and retrieval
I was reading the module's code to learn if another backend (MongoDB, S3, Solr/Elasticsearch, etc.) could be plugged in as an alternate storage backend.
As far as I've seen, the way would be:
- Having the option to disable the DB logging
- Writing a sub-module implementing hook_mail_logger to store the message to alternate backend.
Since there is no hook documentation, I assumed that the hook is provided to plug alternate storage mechanisms, but not being the built-in DB storage in its own hook confuses me a bit. If I'm right, moving the built-in DB storage into a hook_mail_logger would also be in order, and also serve as a nice usage example.
However, I'm not 100% sure if this is the correct way to go and if it would work at all, so advice in advance of doing any work would be much appreciated.
Comments
Comment #2
amonteroComment #3
NancyDruI would like to see more justification for doing this.
Comment #4
amonteroThanks for the prompt response, @NancyDru.
The idea behind the request is to be able to make storage mechanisms switchable/stackable as it's done, for instance, for watchdog. We generate a lot of mail and MySQL is not the ideal storage on our scenario (which we're still evaluating for solutions). If the module allows this to be achived, writing a storage hook for an alternate backend would also be an option for us.
I've updated the OP to reflect this.
Comment #5
NancyDruI would guess that there would be a separate module that would implement the hook and would write the data. That would mean that the install file would have to be split.
Do you want to take a shot at a patch?
Comment #6
amonteroSure, I was thinking into provide alternate storage backend via an external module taking advantage of the hook. However, I would still need the ability to turn off the module's built-in DB storage. A description help text hinting that doing such a thing would only make sense when using an external backend would be in order.
Would such a patch be acceptable?
I don't understand what you mean by "splitting the install file". I don't care of having an empty, unused table. Or you mean that built-in DB storage would be provided as another external submodule, leaving mail_logger only as the common code?
About the patch, I'm just researching on options to provide email archival, ATM. I'm just finding out if using this module would be a viable/valid solution. If it is, would be one of the easiest and quickest of our current options and if we go ahead that path, we would provide all the needed code, indeed.
Comment #7
NancyDruYou may not care about an extraneous table, but many do, including me. The installation would have to account for not creating the table if it is not needed.
Comment #8
amonteroI agree, your point is completely reasonable. The site should be kept clean.
But other than my above module split proposal, I don't see other way to create the table or not, if not needed. Also, on DB storage module uninstall when switching backends the table would be dropped.
Maybe creating and dropping the table on feature enable and disable, but that sounds a bit dangerous, imo.
Can you please elaborate on how would you do that?
Comment #9
NancyDruYes, the storage module would have to create the table on install and drop it on uninstall.
Comment #10
NancyDruComment #11
John Franklin CreditAttribution: John Franklin commentedA simple version of this patch may be to specify the target database, and default to "default." This would let a site developer stand up a second database and log all the mail there, while leaving the main database to manage the rest of the site.
See here for details on setting up multiple databases.