[TYPO3-core] Strategy for deprecation log
Christian Kuhn
lolli at schwarzbu.ch
Tue Apr 2 01:36:29 CEST 2013
Hey,
On 04/01/2013 03:57 PM, Markus Klein wrote:
>> 2) optionally checks for duplicates using the sys_registry
>>>> IMHO a NO GO. Please don't use any database stuff in deprecation handling.
>
>> Why?
>
> 1.) Because I don't think it's a good idea to mix concepts of different "abstraction levels". Database access and handling is a far higher concept than the rather lowlevel deprecation handling. This shouldn't be mixed.
> It MIGHT lead to serious troubles in the (unknown) future, especially when it comes to database functions being deprecated. Somewhat a chicken - egg problem.
Mmmh. I think this is not such a strong argument anymore: db connection
is established after LocalConfiguration & AdditionalConfiguration was
read. There is not much code delivered by extensions that could trigger
a deprecation before (except AdditionalConfiguration ...). Core itself
must be clean anyway in this regard. So, it would be probably possible
to log deprecations to db.
I'm only unsure about two points:
* It might happen that the overcomplicated errorHandler might throw
deprecations at an earlier point (unsure).
* The eid scripts might be a problem, since they don't initiate db
connection by default, but could very well throw deprecations. To solve
that, we could just initiate db connection in eid by default too (that
would also simplify this area in bootstrap a lot). I also think that not
creating db conn in eid is a flaw anyway, because you always need it if
you're doing anything useful. Objections?
> 2.) Accessing the DB is probably even slower than reading the small plain file.
Not necessarily. If we hash the message and create a key on the hash
like Steffen suggested, it won't cost much. Especially, if then only a
little number of inserts / updates are done (imho there should be a
timestamp when the last deprecation of that type was thrown). If we
manage to move the insert / update code to shutdown(), we could gather
the deprecations and commit to persistence with little overhead I guess.
Regards
Christian
More information about the TYPO3-team-core
mailing list