[TYPO3-core] Strategy for deprecation log

[Markus Klein]

Hi!

Still, I'm against using the database for this "feature".

It would be really interesting to have some numbers, how "bad" my patch really is in terms of performance.
And please remember, deprecation log is for DEVOLPMENT only!
Please keep things as simple as possible and don't invest too much time into this. "KISS"

Introducing another dependency like the scheduler is also not my favorite. Usually I don't have any scheduler cronjob running on dev machines.

Kind regards
Markus

-----Original Message-----
From: typo3-team-core-bounces at lists.typo3.org [mailto:typo3-team-core-bounces at lists.typo3.org] On Behalf Of Michael Stucki
Sent: Tuesday, April 02, 2013 11:05 AM
To: TYPO3 core team
Subject: Re: [TYPO3-core] Strategy for deprecation log

Hi!

I agree that something needs to be done about the deprecation log, but yet I'm undecided about Steffens approach. It requires a database connection and it will be slower than writing to the filesystem.

How about a different approach:
- Keep using the file
- Add a scheduler job which cleans up the file once per day

With this approach, no dependencies are added and the performance remains the same. It would allow us to implement the best possible
solution: either use the DB for unique filtering, or create a nicely formatted text report, which is what I currently prefer...

Greetings, Michael

Am 01.04.2013 03:28, schrieb Steffen Müller:
> Hi,
> 
> a lot of people complain about huge deprecation log files with a high 
> percentage of duplicate entries.
> 
> ATM there's a patch pending in gerrit which filters duplicates in the 
> deprecation log [1] to reduce size of these files.
> 
> What the patch does:
> * create a unique token for the incoming deprecation log message
> * load the complete log file,
> * test line by line if token already exists
> * append new line if not existing
> 
> Drawbacks of this approach:
> * bad performance
> * permanently monitoring the deprecation log by running "tail -f" on 
> the cli won't work for duplicates
> 
> Better solution:
> IMO we should use the Logging API for writing deprecation log messages.
> This would give users more control over deprecation log strategy.
> 
> The general approach would be to replace the implementation of
> GeneralUtility::deprecationLog() with:
> 
>   $logger =
> self::makeInstance('TYPO3\\CMS\\Core\\Log\\LogManager')->getLogger('deprecation');
>   $logger->warning($msg);
> 
> In the most simple case, we'd have a FileWriter configured which 
> simply writes to typo3temp/logs/deprecation.log This would be a plain 
> replacement for the 'file' part in GeneralUtility::deprecationLog()
> 
> To filter duplicates we could add a dedicated DeprecationWriter, which
> 1) receives all deprecation messages,
> 2) optionally checks for duplicates using the sys_registry
> 3) writes the log record to the configured target writers.
> 
> I already have a prove of concept for this. [2]
> 
> If you have ideas for more fancy stuff in step 2) - then go ahead and 
> share.
> 
> Questions I have:
> * How to flush the registry from the backend?
> * Should we filter duplicates be default?
> * How to migrate the old configuration from 
> $TYPO3_CONF_VARS['SYS']['enableDeprecationLog']?
> * What is your workflow with deprecation log? (when working on core or
> extensions)
> 
> 
> 
> [1] https://review.typo3.org/#/c/19251/
> [2] https://gist.github.com/t3node/5282732
>