Mark Database class as deprecated about contao HOT 8 OPEN

Before we deprecate something, we must stop using it ourselves, which means you have to create a PR that replaces all usages of the Database class with Doctrine.

from contao.

Really? Just because of the debug bar output?

from contao.

@aschempp What do you mean?

from contao.

Well if we don't mark the class as deprecated, neither we nor the developers will get a suggestion to use Doctrine… You know it's almost impossible to rewrite everything at once.

from contao.

First of all, it is not impossible. It might be a large PR but that's manageable.

Second of all, if we deprecate the class but continue to use it ourselves, people will be confused and uncertain of our deprecation policy.

from contao.

Of course we can deprecate it and move to doctrine then.
The only thing is, we MUST NOT use it for new code.
The migration away will take a significant amount of time, do you really want people to continue to use it in future code just because we did not deprecate it because we still use it in legacy code that is subject to removal anyway?

from contao.

Before we definitely know that Doctrine DBAL is suited to replace the database class (which I doubt because of the features that the database class implements), the class is not subject to removal at all.

from contao.

I wonder which features you are referring to here that should be missing by using the plain doctrine database.
Granted, some things are missing but these are merely syntactic sugar like the reset and loop over again.
However I always was hesitant to use this for sake of memory usage (as the results were always buffered). When I want to buffer them and loop over again and again, I buffer them locally and not in the fetched result.
Therefore these "missing" features are easy to cope with (in fact I see the removal of these features as feature on it's own).

from contao.