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

amontero created an issue. See original summary.

amontero’s picture

Issue summary: View changes
NancyDru’s picture

Status: Active » Postponed (maintainer needs more info)

I would like to see more justification for doing this.

amontero’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Active

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

NancyDru’s picture

I 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?

amontero’s picture

Sure, 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.

NancyDru’s picture

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

amontero’s picture

I 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?

NancyDru’s picture

Yes, the storage module would have to create the table on install and drop it on uninstall.

NancyDru’s picture

Status: Active » Needs work
John Franklin’s picture

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