[FEATURE] Upgrading to DBAL 3 & Switch to symfony/cache

[seifane-wise]

Changes proposed in this pull request:

• Upgrade to DBAL3
• Use symfony/cache for cache since doctrine/cache as been deprecated
• Remove usage from deprecated / deleted classes of DBAL3

I saw too late that a PR was already open concerning this change. I don't know the progress that has been made by @eigan so I opened this one and maybe we can merge our efforts. I think I was able to clear most of the deprecated classes usage in DBAL3. Most significant change is on the cache side where I replaced doctrine/cache by symfony/cache. It broke a lot of tests and I think I managed to fix most of them "correctly". Let me know what you think, if I missed something huge, or if you want to take a different approach on this.

I've been using a version of this branch on my project with no issues so far but I didn't test everything.

Some of the classes I removed (most of them related to codegen) are deprecated on doctrine and will not be replaced by anything. I would argue that if doctrine doesn't want to support codegen anymore it's not the role of this package to implement it. It also keeps the code to a minimum which is easier to in the long run. :)

Link to the doctrine issue (https://github.com/doctrine/orm/issues/8458)

Link to related PR on laravel-doctrine/migrations (https://github.com/laravel-doctrine/migrations/pull/118)

[eigan]

Could you rebase on laravel-doctrine/orm 1.8. Some of your commits (L9) was cherry-picked and thus have a new sha1. The original commits are now trying to be a part of this PR :)

EDIT: Some of your commits are duplicates of existing commits, for some reason *

[eigan]

@dpslwk Any thoughts? I know you tried to use illuminate/cache (which I would prefer, since it is most likely required by all who use this package), but there was some issues?

[seifane-wise]

@eigan I rebased from 1.8 but some they were some conflicts on composer.json that I had to edit. I may have messed up something during rebase that cause this weird commit history. I just committed in response to your review.

Concerning the use of symfony/cache it is a suggested dependency of illuminate/cache if that helps my case :). Also it is recommended by the doctrine team and makes integration easier.

[eigan]

@seifane-wise When you rebase, drop the commits not from you. If using git rebase -i upstream/1.8 can you replace pick with drop at the commits. Looks like at least three commits(?) dated march 2.

[seifane-wise]

@eigan should be good now. commit are correctly rebased.

[codecov-commenter]

Codecov Report

Merging #520 (3211441) into 1.8 (e97d145) will increase coverage by 1.95%. The diff coverage is 62.85%.

@@             Coverage Diff              @@
##                1.8     #520      +/-   ##
============================================
+ Coverage     57.17%   59.13%   +1.95%     
+ Complexity      828      691     -137     
============================================
  Files           101       94       -7     
  Lines          2314     1982     -332     
============================================
- Hits           1323     1172     -151     
+ Misses          991      810     -181     

Impacted Files	Coverage Δ
src/Auth/Passwords/DoctrineTokenRepository.php	94.59% <ø> (-0.15%)	:arrow_down:
...onfiguration/Connections/MasterSlaveConnection.php	100.00% <ø> (ø)
src/Configuration/CustomTypeManager.php	100.00% <ø> (ø)
src/Configuration/MetaData/Config/ConfigDriver.php	100.00% <ø> (ø)
src/Console/ClearMetadataCacheCommand.php	0.00% <0.00%> (ø)
src/Console/ClearQueryCacheCommand.php	0.00% <0.00%> (ø)
src/Console/ClearResultCacheCommand.php	0.00% <0.00%> (ø)
src/DoctrineManager.php	87.17% <ø> (+0.51%)	:arrow_up:
src/DoctrineServiceProvider.php	0.00% <ø> (ø)
src/Loggers/EchoLogger.php	100.00% <ø> (ø)
... and 47 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update e97d145...3211441. Read the comment docs.

[dpslwk]

not sure about the removal of the YAML in this, does that break the yaml mapping for entities? I thought that we would not need to remove that until orm 3.x, not dabl 3.x

[seifane-wise]

sorry @dpslwk I didn't you had plans to remove it in the future. I had a glance over all deprecated class usage and removed as much as I could as I was trying to future proof as much I could right now. Maybe this branch should also be a new version like my PR on migrations ? 2.x or 3.x ?

[SCIF]

Hey guys,

First of all, am highly appreciate your work!

It's 2.5 months past last activity. Is there any chance to get this stuff done? Moreover, doctrine team has advised in January to migrate to 3.x branch

[dpslwk]

sorry @dpslwk I didn't you had plans to remove it in the future. I had a glance over all deprecated class usage and removed as much as I could as I was trying to future proof as much I could right now. Maybe this branch should also be a new version like my PR on migrations ? 2.x or 3.x ?

I really think the YAML meta data driver should be restored, that is deprecated with ORM and will be removed in ORM 3.x its not related to DBAL 3 Yes we will need to address this when ORM 3 is eventually released Side note my main project that uses ORM and the main reason for my work here currently uses YAML mappings, the longer I can put off having to rewrite 63 mappings the better ;)

[seifane-wise]

Sorry I am closing this PR as I dont have the time to maintain it anymore. I will leave my branch open if someone want to base off of it. :pray:

[eigan]

@seifane-wise Understandable! Thanks! 🙂