-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(dev/core#4999) Support Entity Framework v2 for extensions #331
base: master
Are you sure you want to change the base?
Conversation
Nice! @totten don't let this be a blocker but just wondering if the upgrade scenario has been considered? Where a new entity is added to already installed extension and needs to install that entity on upgrade. Maybe there is a function we can call from the upgrader? |
I agree this would be beneficial. In the upgrade scenario you can't just read from the current schema and add that table as-is, because the table might change in the future, so your upgrader has to provide a snapshot of the table structure as it first appears. And we do want to leverage the goodness of the auto-detect-collation here. So a utility function would be great that you can feed in a table definition as an array and it spits out the |
Thanks, good points about upgrading @mattwire @colemanw. (Aside: I got so far into the rabbit of hole of "how to polyfill an upgrader class" that I kind of stopped thinking about the design of the upgrader-class being delivered...) Probably the most direct thing is like you say -- add a helper function. It feels like this means switching the class-relationship.
(I agree that adding the specific helper function probably shouldn't be a blocker. I'm not certain if it's easy or hard. But there should be a clear place to put that kind of helper.) FWIW.... there's almost enough information to do updates like I guess you could unify the sequences. Values like I dunno, that sounds a little radical. For the moment, probably better to think about how to add helper function. |
... or to keep it very explicit: |
7f93601
to
f47e96b
Compare
I've pushed a set of updates (but haven't updated description yet). Basically:
|
f47e96b
to
c769231
Compare
civibot, test this please |
So I rebased and switched this from the unreleased
|
@totten what's the status of this? |
@totten I've just finished converting the rest of our core extensions to use this. |
516ed6a
to
a5ecaad
Compare
Ah, blerg. There's a test-interaction problem (i.e. tests pass individually but fail in bulk). E2E tests look like this: $this->civixGenerateModule(static::getKey(), [
'--compatibility' => '5.69',
]);
$this->civixGenerateUpgrader();
$this->civixGenerateEntity('Bread');
$this->civixGenerateEntity('Sandwich');
tldr: I need a separate PR to change the testing process. |
5778108
to
4931342
Compare
civimix-schema@5.72
Co-authored-by: colemanw <coleman@civicrm.org>
This provides parity with the old command. You get to the same output by either of these paths: 1. Make an entity in old civix, then convert the entity 2. Make an entity in new civix
This is a bit smelly. But it would take some poking to figure how if there's really anything wrong here.
* This approach defines `CRM_*_DAO_Base`. * When deployed on 5.74+, `CRM_*_DAO_Base` will be exactly the same as `CRM_Core_DAO_Base` In other words: class CRM_Foo_DAO_MyData extends CRM_Foo_DAO_Base {} class_alias('CRM_Core_DAO_Base', 'CRM_Foo_DAO_Base'); class CRM_Core_DAO_Base extends CRM_Core_DAO {} * When deployed on <5.74, `CRM_*_DAO_Base` will use the anonymous backport variant from civimix. In other words: class CRM_Foo_DAO_MyData extends CRM_Foo_DAO_Base {} class_alias('CiviMix\Schema\Foo\DAO', 'CRM_Foo_DAO_Base'); ^^ Read anonymous class... which extends CRM_Core_DAO * In this arrangement, the anonymous DAO implementation is -only- used on old versions. Once you get to 5.74+, you use the local base. This should provide better IDE hints and simpler callstacks. You presumptively do not get backports of changes/improvements in the DAO base.
Overview (Final)
Implement support for Entity Framework v2 (EFv2; aka dev/core#4999). This is a general overhaul of everything related to
generate:entity
. There's a more complete comparison of changes at: https://github.com/totten/civix/wiki/Entity-TemplatesThe PR was originally opened to address one major sub-problem (installation and SQL generation). I'm preserving that description so that the discussion remains intelligible. However, the ultimate scope of the PR evolved to cover more aspects of dev/core#4999 / EFv2. The wiki page gives a more comprehensive summation.
(Subject: Auto-generate SQL during installation via
civimix-schema@5.72
)Overview (Original)
For extensions that use
generate:entity
/generate:entity-boilerplate
, this changes the SQL lifecycle:auto_install.sql
andauto_uninstall.sql
).ping @colemanw @mattwire @artfulrobot @christianwach
Before
civix generate:entity-boilerplate
readsxml/schema/**.xml
and generates SQL files (sql/auto_install.sql
andsql/auto_uninstall.sql
).utf8
vsutf8mb4
).After
CiviMix\Schema\Automatic\MyModule
CustomGroup
s.civicrm-core
and backported viacivix
. As with mixins, it will check the<compatibility>
when deciding whether a backport is needed. At runtime, it will look to core-code and extension-code and choose the newest version.civix generate:entity-boilerplate
does not generate SQL files.civix upgrade
will prompt you apply the following changesRelated PRs
mosaico.git
with (Draft) Installer - Auto-generate SQL to match local schema veda-consulting-company/uk.co.vedaconsulting.mosaico#635TODO
generate:upgrader
should set<upgrader>CiviMix\Schema\Automatic\MyModule</upgrader>
.civix.phar
. (I've been testing local git copy.)