Details
-
Type:
Improvement
-
Status: Done/Fixed
-
Priority:
Trivial
-
Resolution: Won't Fix
-
Affects Version/s: 4.3.0
-
Fix Version/s: Unscheduled
-
Component/s: Core CiviCRM
-
Labels:
-
Documentation Required?:None
-
Funding Source:Needs Funding
Description
This should reduce the training and wait-time related to GenCode.
Policies:
- DAO's go into SCM
- Generated SQL files for the default (English) language go into SCM (because this is what developers use most of the time)
- Translated SQL files do NOT go into SCM (but can be produced with GenCode if a developer needs them)
- ListAll.php goes into SCM
- UNDECIDED: civicrm.config.php
- UNDECIDED: civicrm-version.php
- UNDECIDED: CRM/common/version.tpl
(For version.tpl, I think we could make this file optional at runtime, but the other two files are a bit trickier.)
Attachments
Activity
It would be great to be able to run GenCode on an extension as well (rationale: an extension might have a new table and need DAO+sql generated from xml/schema)
GenCode.php eu.tttp.exampleextension
As for civicrm-version.php, it's needed to get the / civicrm/upgrade working (ie. to apply schema changes), right? in that case, as the DAO is already assuming the schema is the new one, would make sense to have the upgrade script ready to run too, hence including civicrm-version too
PR on its way...
Generated files in the repository are painful on merges etc. I suggest the opposite approach: restructure GenCode so it only generates the things that actually changed, i.e. really need regenerating – preferably using a Makefile. That way running it is no problem, as it only takes longish on the first run.
I would like to note that I am REALLY keen to see the restructure where packages, civicrm-core, cms folders sit @ the same level & no folders are added to civicrm-core.
@Olaf: you don't have to merge the DAO, the latest version generated is always the good one. It has been discussed for a long time, the consensus has been reached and the pros of the DAOs inside are deemed more important than the cons.
@Eileen. different issue, but keep an eye on Tim's magic install tool to create a dev environment when it's released. It's awesome
Seems like in the 3 years since this issue was opened we've taken a different approach and now all the grunt work is scripted by buildkit.
So it seems this issue, while not entirely moot, is at least very low priority.
I think it should be closed unless/until someone is actually working on it.
Some options for the config/version files:
For a 4.3 timeline, I'd feel better about refactoring GenCode than digging into each file. From my perspective, it's pretty easy to take a snapshot of GenCode's outputs, refactor, rerun, and validate that the new outputs match.