A few of us have started exploring how we can integrate Doctrine into future versions of CiviCRM. A large part of this work was initiated by Peter Haight from Giant Rabbit who explained his thinking and approach in this blog post on Persistence Refactoring. One of our goals for the next few releases of CiviCRM is to improve the technology backbone that Civi is based on. It made sense to most of us to start from the database layer and then move outwards and using doctrine and working with peter seemed a good logical next step.
We decided to spend 3 weeks (till mid january) on various exploratory sprints and try and answer a few questions and see how things are done in the doctrine/symfony world of things. We also decided to start adopting more scrum - like technques and iterate on a weekly basis. Our goal is to come up with a list of things that we are curious about going forward and work on some potential answers during the week. So without further ado, here are some of the things that we decided to investigate and research this week:
- Analyze our form / page php code and the api layer and get a feel for the structure of the code base, how much replication, how many simple forms, how tightly coupled is the api and BAO.
- Get a better idea on the power and complexity of Doctrine annotations. Can we use them to store field meta data similar to what we have in the current xml files. What can we learn and borrow from Drupal 8 in this regard.
- Generate the doctrine entities file automatically from the xml files. This allows us to tranisition a lot of the information currently present in the xml files. In a nicely timed move, Adam Wight started on this work independently a few weeks back.
- Can we use some tools based on top of doctrine / symfony to make CRUD operations easier? We explored Sonata Admin to see if we could make writing simple CRUD forms, pages and listings trivial. Considering the number of tables in CiviCRM, making this easy to do is very important.
- How hard would it be to convert our code base to Doctrine from our current DAO layer?
- Get a doctrine branch on github to coordinate all current work.
You can visit our current issue board for this weeks sprint on our JIRA Agile dashboard. We still have a lot more questions and queries that we'll investigate over the next few weeks before we decide on our plans for integrating doctrine et al into CiviCRM.
If you are interested in joining these exporations and helping us find a few answers ping us on IRC. We'll blog on a regular basis and keep folks updated on our progress and current thinking.
Comments
Completely applaud the initial investigations led by Giant Rabbit that are carried out by core team in the sprint-based code explorations to get doctrine as the ORM solution for CiviCRM. This is awesome stuff and what we need to modernize the entire stack!
However just as any large non-profit organization wanting to adopt a CRM solution and replace their legacy systems with CiviCRM, I think it makes sense for us as a community with more than 5000+ (or is it 8000+ now?) installs to reach out to the project maintainers of Doctrine to ensure our adoption of and transition to their ORM is a success.
Here are some of the most pressing questions we should address IMHO:
Refactoring work is very hard work and I think the core team is doing an awesome job at tackling these ORM specific implementation explorations early on, hopefully with lots of discussions within the core team and API team about the overall architecture of the new and better CiviCRM.
Young-Jin
Hi young-jin,
You rised really good points. Could you take the lead and contact doctrine on these?
Also, who knows, they might be looking for case studies and stories as much as we are, they might be interested to hear about our migration with civi.
Young-Jin suggests some really good questions!
Bravo, this is really fantastic news! And thanks for keeping us updated on your progress.
Ideally the BAO layer should isolate the rest of the code from replacing the DAO with Doctrine, but alas we all know this is not the case. So the refactoring will most probably be a humongous task, and specifically in the Forms layer.
Which leads me to the point that finding a successor to the Forms layer should also be tightly coupled with this investigation, and both refactorings most probably happen at the same time in the future. As Eileen said, more of a 5.0 than a 4.5 ...