Chop up the package

[fprochazka]

Motivation:

Doctrine can be used without the suggar added by Kdyby and the suggar should be usable in projects that are not using Nette.
Splitting the package makes easier having control over what is in your project and also benefits sf and other framework users.

Todo:

• kdyby/doctrine-dql-repositories (better name?)
  • EntityRepository (possibly as a trait, to allow mixing more repository features to default one, without extensive rape of inheritance)
  • customized QueryBuilder (maybe create another repo for this one and make the repositories repo depend on it?)
• kdyby/doctrine-query-object
  • QueryObject
    • build-in events for select & filter callback array
    • public api for "getting" the actualy generated query for custom purposes (or passing it somwhere else)
  • ResultSet
    • simplify
  • EmptyResultSet
  • pořešit nějaký api na result cache
  • přidat poděděnej QueryObject, kterej bude přijímat EM už v konstruktoru
• kdyby/doctrine-collections-readonly
• kdyby/doctrine-collections-lazy
• kdyby/doctrine-magic-accessors
• kdyby/doctrine-nette-reflection
  • RuntimeReflectionService
• kdyby/doctrine-non-locking-unique-inserter
• kdyby/doctrine-dbal-batchimport
  • Kdyby\Doctrine\Helpers::executeBatch()
  • Kdyby\Doctrine\Helpers::loadFromFile()
• drop
  • geo
  • dao
  • enum
  • custom dbal exceptions (solved long time ago natively)
  • autodiscovery of repository<=>entity, make it a configuration section without magic (it should configure listeners that will override metadata settings appropriately)
  • DqlSelection & Dql namespace ... as I'm not using it and I don't know about anybody who is
  • Persistence namespace (relevant interfaces will be moved to relevant repositories)
• kdyby/doctrine - OrmExtension
  • will have "load" sections for all the packages, so just installing them via composer should be enough to enable them (or most of them), but should work without any of them
  • add "optional dependency extension settings" - the better alternative to Provider interfaces

[enumag]

I'd probably not chop it all the way to single-class packages if I were you but I don't really mind either. 👍

kdyby/doctrine-dql-repositories (better name?)

possibly just kdyby/doctrine-dql? By the way this will need some thinking because the EntityRepository contains a fetch method for QueryObject and you want to drop the Persistence namespace which contains an interface for QueryObject used by fetch. Possibly kdyby/doctrine-query-object would depend on this package? (Certainly not the other way around.)

EntityRepository as a trait

I'd maybe use multiple traits for the different features.

drop

I don't use any of the features you want to drop. Or at least I don't think I am. So 👍 for that. :-)

[enumag]

Oh and anything console-related should probably be separated as well - and the kdyby/console dependency should be dropped. What do you think?

[enumag]

Also I'd like to be able to remove kdyby/events from my projects completely. Any chance of kdyby/doctrine not depending on it?

EDIT: Sorry if this is a wrong place to ask for it. Should I open a new issue?

[juniwalk]

kdyby/doctrine-readonly-collection
kdyby/doctrine-lazy-collection

Why not just kdyby/doctrine-collections and merge them into one package?

[fprochazka]

the EntityRepository contains a fetch method for QueryObject

That should be removed. It doesn't really make any sense to have the fetch method on repository, since PHP doesn't know generics. The Persistence namespace won't be completely dropped, the QO related stuff will probably be refined and moved to the QO-related repository.

I'd maybe use multiple traits for the different features.

Exactly :)

Oh and anything console-related should probably be separated as well - and the kdyby/console dependency should be dropped. What do you think?

Discuss that here please #190.

Also I'd like to be able to remove kdyby/events from my projects completely. Any chance of kdyby/doctrine not depending on it?

Definitely new issue, I might be in for an optional switch between symfony-something and kdyby/events... But... new issue :)

---

@juniwalk well, people are almost iracionally obsessed with minimalism theese days, but chopping it up doesn't really hurt anything (except maintenance cost)... Also, if it has strictly defined name like doctrine-readonly-collection the discussion whether a new class, for example SomeMagicCollectionsHelper should be added here, or in new package doesn't even happen, since it is obviousely out of the scope of the package.

[juniwalk]

@fprochazka quilty as charged, I do love minimalism :D

[TomasVotruba]

👍

[foxycode]

@fprochazka Can I help with something?

[fprochazka]

@foxycode well, the tasks require a lot of "management work", so if you wanna help, I'd encourage you to start with the code cleanup, which means dropping theese (preferably in several pullrequests, not in one)

• geo
• dao
• custom dbal exceptions

[juniwalk]

@fprochazka I think ancient PRs and issues that are no longer relevant should be cleared too. Also after chopping up some of them may become irrelevant as they would be for code in different repository.

[foxycode]

@fprochazka Ok, I look into it.

[foxycode]

@fprochazka I have first commit prepared. I'm not sure how to make PR separate from #243, Do I need to create own branch or is there simpler way?

[fprochazka]

@foxycode yes, creating PR's from master is an anti-pattern. You should create new branch for each PR.

[fprochazka]

If somebody wants to help, here are some usefull tasks https://github.com/Kdyby/DoctrineDbalBatchImport/issues

[enumag]

TODO: optional dependencies

• Events: Independency on Kdyby/Events #239 (PR Make Kdyby/Events optional #266)
• Console: Make Kdyby\Console optional #190
• Annotations: Is Kdyby/Annotations dependency necessary? #268

[Olicek]

Is this still in progress?

[fprochazka]

It's still planned, but I have very little time currently.

[enumag]

@fprochazka I think we should split doctrine/dbal integration into its own package as well. Sometimes I want to only use the DBAL without the ORM. What do you think?

[fprochazka]

@enumag I'm not against it. Let me think about that.

[fprochazka]

TBD: throw away QO and suggest https://github.com/librette/doctrine-queries ?

[fprochazka]

More clear separation of repository magic would be nice #182

[fprochazka]

If we ignore the extra functionality, that will be extracted to separate packages (I consider a pretty straightforward problem), I have an updated proposal:

The Plan

• minimum requirements:
  • PHP 7.1 and newer
  • Nette 2.4 (3.0 will be solved as separate major release, once it is actually released)
  • Current stable Doctrine packages (once the 7.1 only versions are released, all packages will increase the requirement to those versions with new major release probably)
• Kdyby/TracyDoctrineDbalPanel
  • a Tracy panel, that will handle only SQL queries and highlighting in the Tracy Bar
  • secret idea to solve showing executed DQL in panel
• Kdyby/Doctrine
  • DoctrineExtension that will have the same configuration structure as Symfony (doctrine: dbal: ... and doctrine: orm: ... sections)
    • the convention with Symfony is to have under_score config notation but most Nette extensions have camelCase notation => the structure should be the same, but camelCase
    • integration with ProxyManager to allow easier reseting of EM
  • ManagerRegistry
  • ConnectionFactory
  • ProxyAutoloader (for when entity proxies are store in sessions)
  • DI
    • ContainerAwareEventManager
    • ContainerAwareEntityListenerResolver
  • Caching
    • CacheCleaner
  • Logging
    • an SQLLogger that will handle only SQL queries piping into Psr\Log\LoggerInterface
      • this is a replacement for the FileLogger - instead of implementing every custom logging mechanism, just use Monolog to pipe the queries where you want them - to files in this case
  • Tracy
    • BluescreenRenderer - all exception rendering that adds panels to bluescreen
    • UnitOfWorkSnapshotRenderer - currently the panel depends on wiring into EntityManager but if a listener was created, that would create snapshot of UoW before every flush, this dependency could be removed
    • SecondLevelCacheStatsPanel
  • and other similar classes required for bridging the packages
  • console commands proxies - same as DoctrineBundle
  • require
    • Kdyby/TracyDoctrineDbalPanel
  • everything else will be optional

Open questions:

queries higlighting

idea:

• Kdyby/TracyDoctrineDbalPanel
  • this library will define custom QueryFormatter interface with a very simple implementation, that will only format parameters into the query with no highlighting
• Kdyby/DoctrineDbalQueryFormatter
  • an SQLLogger that will handle only SQL queries piping into Psr\Log\LoggerInterface

or

• just have it in TracyDoctrineDbalPanel, but abstract it away with interface anyway to allow changing the behaviour

I will probably do it the second way because it's way easier