Added an admin page to display Backtrace from watchdog

It was patched over a version with #536528: DataSync should catch exceptions and mark the job as failed and #536512: Datasync should not set the memory_limit itself patches applied, but I don't think it should break if you don't have the last one.

1) I agree

2) I don't think so. First implementation on my side was on a separate table. The fact it was unnecessary for only field.

3) Ok, with an implementation with a hook your point of view on 2) is better.

The thing is, you have to do a delete operation on hook, when you delete a job, don't keep trace of backtrace, so, this need a datasync_job_delete() function implentation (like I did in drush integration file).

Ok, thanks

Hello again!

I'm actually rewriting this feature as a new module. I wish you could review it when I'll upload it here. I wonder if you could create a contrib/ sub dir in your module repository and allow me to put this as a submodule, and the drush integration (#541784: Drush integration) with it?

The fact I'm not fond of creating a new module project for each of these single features.

What do you think?

Note about datasync.job.inc
Lines 141 to 147:

      try {
        //THIS ACTUALLY RUNS THE PHASE
        $result = $this->{$this->phase}();
      }
      catch (Exception $e) {
        $result = t("Exception caught: %exception", array('%exception' => $e->getMessage()));
      }

This code should also export $e backtrace so I could get it in the hook_datasync_exception_thrown(). The main goal of this submodule is not debug DataSync itself, but debug the custom implementation.

Please review and try this.

I totally agree with the configuration granularity you are proposing. There is a lot to do with this submodule. I'll take some time as soon as I can to continue improvements on this module.

When you are doing this:

      try {
        //THIS ACTUALLY RUNS THE PHASE
        $result = $this->{$this->phase}();
      }
      catch (Exception $e) {
        $result = t("Exception caught: %exception", array('%exception' => $e->getMessage()));
      }

You are catching every exception that may happen in the custom job implementation. In my case, I throw some custom exceptions (EntityException in my module) that I want to be catched by your module if I forgot the right catch statement in my job implementation (plus, some PHP low level exceptions could be thrown too).

The thing that is wrong in this code is you get back exception message but not the backtrace of the custom exception (remember that my exception is not a DataSync exception, but a custom exception which comes from an API which is not DataSync related).

I don't have my working laptop with me right now, so I can't do a quick and dirty patch to show you, but I hope this clarify what I try to explain.

What I want to get back here, is the custom exception backtrace, not just the error message, so when you throw the hook_datasync_exception_thrown() I can get it back in the submodule to log it.

Remember that I does this module to debug my custom jobs, not to debug DataSync itself. But the idea to do a granular multi-level logging is still a really good idea.

Please try this one, and tell what do you think.

EDIT: oups, I'm tired, rename the file to .tar.gz (typo error)
Re EDIT: please avoid diff if you modify it, I did put the module into a different folder this is like hell to apply:)

This version is quite buggy, I'll send a new one soon (I'm currently workig with, I really needed this feature).

Here is an updated version, with no known bugs for me.

@andrewlevine

Did you looked at the code update?

Ok, there is no hurry here, I'm currently using the code I gave you on some sites. But whenever you create a new datasync release I just want to make sure that day my code will continue to work :)

It's not flawless, and I think it can be better, I need you to tell where I do a wrong usage of your own hooks and if you're comfortable with the way I do all those things.