Publicado
2014-01-09 10:50
As lobo mentioned in his previous blog, we have been experimenting on Doctrine integration with CiviCRM. So in the following week we focused on few specific tasks:
-
Investigate triggers / stored procedures in doctrine
Doctrine does not have explicit support for triggers and stored procedures. In the past they have not encouraged it and have an alternative called "lifecycle callbacks". For more infor: http://symfony.com/doc/current/book/doctrine.html#lifecycle-callbacks ( CRM-13989 )
-
How to add custom / Civi annotations to doctrine entities
We were able to add Civi annotation with caching in a symfony environment. ( CRM-13987 )
-
CiviCRM + Symfony + Doctrine make them play nicely
We were able to bootstrap CiviCRM under Symfony and use doctrine for few simple db operations. ( CRM-13985 )
-
Generate Entities from xml
We store lot of schema related data in xml files. So goal was to generate entities which will can be used by doctrine. Most of the times our generated entities worked well with Doctrine, with some minor glitches.
-
Doctrine REST api
The goal for this was to check if there are any existing rest api bundles which can be directly used for api running on doctrine. We evaluated few things like http://leedavis81.github.io/drest/ ( CRM-13986 )
-
Improve custom data and custom field structure
How can we make doctrine aware of newly created tables for custom groups, so that we can directly perform CRUD operations. This is still a work in progress. ( CRM-13990 )
You can check our sprint progress in jira, click here
We also welcome anyone who feels adventureous and would like to help in this quest. So feel free to ping us on #civicrm irc channel.
Filed under
Comments
Kurund ... fantastic that you are launching into these experiments/evaluation and keep us regularely updated. Thanks much.
Any feedback so far on Doctrine in the context of CiviCRM? Has you experience been positive overall? Have you encountered any concerning issues / potential show-stoppers? How much of a rewrite would we face if we decided to move to Doctrine? How would you position Doctrine vs DAO & BAO in a new architecture?
As mentioned above we were able to do basic CRUD functions using Doctrine. So basically we generated entities in Doctrine for current schema and successfully used it for CRUD operation. It worked well for simple forms like location type.
I would say it's too early to jump onto any conclusion on doctrine will get intergrated into CiviCRM. There are few issues but I won't consider them as show-stoppers. We haven't decided yet on new architeture, but there are several ideas floating around with regard to BAO, API etc.