Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved the Raven handler when using a Buffer handler #203

Merged
merged 1 commit into from
Jul 28, 2013
Merged

Improved the Raven handler when using a Buffer handler #203

merged 1 commit into from
Jul 28, 2013

Conversation

fabpot
Copy link
Contributor

@fabpot fabpot commented Jun 15, 2013

The Raven handler should behave a lot like a mail handler when used in a Buffer handler. This PR addresses this use case.

@stof
Copy link
Contributor

stof commented Jun 15, 2013

why setting a second formatter ? If someone wants to provide a different formatting for batched messages, it is already possible as your batch method uses formatBatch

@fabpot
Copy link
Contributor Author

fabpot commented Jun 16, 2013

How?

@stof
Copy link
Contributor

stof commented Jun 16, 2013

a formatter has 2 methods: format and formatBatch. If you want a special logic when formatting batch (in this case, using a different line format), you can provide a different implementation of the formatter. So IMO, your batch handling should use the formatter set in the handler instead of a second one set as logFormatter.

@fabpot
Copy link
Contributor Author

fabpot commented Jun 16, 2013

So, you mean that it would be better to create a special formatter for Raven extending the line formatter but with a different pattern for format and formatBatch?

@stof
Copy link
Contributor

stof commented Jun 16, 2013

if we really need a different format for the single and batch formattings, I would say yes

@fabpot
Copy link
Contributor Author

fabpot commented Jun 16, 2013

We definitely want a different format for the single and the batch formatting. For the former, we only want a minimal amount of information as it is used as the title of the report, but for the logs, we want as much information as possible. And the line formatter fits well for both purposes.

Creating another formatter just for that use case seems wrong to me.

So, I think what I propose is actually better. ping @Seldaek

@Seldaek
Copy link
Owner

Seldaek commented Jun 25, 2013

I'm not really against having a second formatter if there are two formats needed, but I am not sure that picking the last record as the main one is right. This sounds very dependent on the exact use case and not very generic. I am especially worried about using the level of the last record to determine whether to log or not. In theory all records should be filtered according to their level first, and then maybe you could take the last one as the one for the "subject" line.

@pvanliefland
Copy link
Contributor

I also wanted a nice buffered logging for Sentry so I tried @fabpot's version.

@Seldaek you're right : for me, picking the last record does not work, as the last record is a debug entry (kernel.terminate). Filtering all the records based on their level seems to work.

As for the subject line, I ended up taking the record with the highest severity, as it is usually the problem I want to log.

Apart from that, Fabien's version works like a charm.

Here is my slightly modified writeBatch method:

public function handleBatch(array $records)
{
    $level = $this->level;

    $records = array_filter($records, function($record) use($level) {
        return $record['level'] >= $level;
    });

    $record = array_reduce($records, function($highest, $record) {
        if($record['level'] >= $highest['level']) {
            $highest = $record;

            return $highest;
        }
    });

    // the other ones are added as a context item
    $logs = array();
    foreach ($records as $r) {
        $logs[] = $this->processRecord($r);
    }

    if ($logs) {
        $record['context']['logs'] = (string) $this->getLogFormatter()->formatBatch($logs);
    }

    $this->handle($record);
}

@Seldaek
Copy link
Owner

Seldaek commented Jul 11, 2013

@pvanliefland can you send a pull request against @fabpot's repo to update this pull request? Or @fabpot just copies the changes? Or someone says if they disagree, but it seems like a better way to me?

@pvanliefland
Copy link
Contributor

Done. Tried this approach with 2 different projects, looks ok to me.

Amended PR #203 (RavenHandler batch improvements)
@fabpot
Copy link
Contributor Author

fabpot commented Jul 23, 2013

👍

Seldaek added a commit that referenced this pull request Jul 28, 2013
@Seldaek Seldaek merged commit 6dd92e4 into Seldaek:master Jul 28, 2013
@Seldaek
Copy link
Owner

Seldaek commented Jul 28, 2013

Alright, merged. Just FYI I renamed the *LogFormatter stuff to *BatchFormatter.

wa0x6e pushed a commit to wa0x6e/monolog that referenced this pull request Oct 23, 2013
Filtered records based on their level
Took the record with the highest severity as the main one
wa0x6e pushed a commit to wa0x6e/monolog that referenced this pull request Oct 23, 2013
wa0x6e pushed a commit to wa0x6e/monolog that referenced this pull request Oct 23, 2013
mathroc pushed a commit to mathroc/monolog that referenced this pull request Dec 30, 2013
Filtered records based on their level
Took the record with the highest severity as the main one
mathroc pushed a commit to mathroc/monolog that referenced this pull request Dec 30, 2013
mathroc pushed a commit to mathroc/monolog that referenced this pull request Dec 30, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants