Refs #136 - Update dynamic schema on all ZEO clients on change

[avoinea]

Fixes #136

[mister-roboto]

@avoinea thanks for creating this Pull Request and help improve Plone!

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass.

Whenever you feel that the pull request is ready to be tested, either start all jenkins jobs pull requests by yourself, or simply add a comment in this pull request stating:

@jenkins-plone-org please run jobs

With this simple comment all the jobs will be started automatically.

Happy hacking!

[avoinea]

@jenkins-plone-org please run jobs

[jensens]

Simple and elegant to use the _p_mtime as part of the generated schema name!

[jensens]

@jenkins-plone-org please run jobs

[jensens]

@jenkins-plone-org please run jobs

[avoinea]

@jensens I'll take a look at the remaining failing tests...

[avoinea]

@jensens I don't know what is wrong with this one https://jenkins.plone.org/job/pull-request-5.2/1643/testReport/junit/(root)/(empty)/schemaeditor_txt/ and where it comes from.

For the rest, I added PRs within plone.app.dexterity and plone.app.contenttypes

[ale-rt]

LGTM, thanks a lot!
Please, consider removing that log.info statement added by this PR or to change it with a log.debug.

[ale-rt]

@jenkins-plone-org please run jobs

[ale-rt]

@jenkins-plone-org please run jobs

[ale-rt]

@avoinea The Python 3.7 test failure looks unrelated, but there is a real issue with https://jenkins.plone.org/job/pull-request-5.2/1652/testReport/(root)/(empty)/schemaeditor_txt/

Anyway we are close to have this merged :)

[avoinea]

@ale-rt Hmmm:

plone.app.relationfield-2.0.2-py2.7.egg/plone/app/relationfield/tests/../schemaeditor.txt

[avoinea]

@ale-rt @jensens See plone/plone.app.relationfield#31

[ale-rt]

@jenkins-plone-org please run jobs

[avoinea]

@ale-rt @jensens How can we have this released also for Plone 4.3.x?

[ale-rt]

According to https://github.com/plone/buildout.coredev/blob/a4af25bfde395a999844324b45b9912952a6731e/sources.cfg#L45 4.3 usese the plone.dexterity 2.2.x branch.
Theoretically you can backport the patch there before the 4.3.20 is release, see plone/Products.CMFPlone#3166.
I guess other packages will need fixes like the one involved in this PR.

Sincerely I would save myself from that pain.
Also personally I am not sure I will want to approve it.
In the past we had even simpler backports to 4.3 that caused major pain.

@mauritsvanrees what do you think about backporting this PR to 4.3?

[mauritsvanrees]

Plone 4.3.20 has already been released on 28 August. It has been waiting since then for a Universal Installer.

I don't mind doing a release from the plone.dexterity 2.2.x branch, but it will never get in an official release.

[mauritsvanrees]

BTW, the same is true for Plone 5.1.7: it was released a week ago, but waiting on installer. It is the last release from the Plone 5.1 series, so any updates to the relevant plone.dexterity branch, 2.6.x, would not get in an official release.
Again, an individual package release is still possible.

[tisto]

@avoinea in plone.restapi we have tests that check for undocumented changes in our auto-generated API docs. This PR causes the auto-generated behavior names to change for every test run:

https://github.com/plone/plone.restapi/pull/1033/checks?check_run_id=1572135872

Therefore it is impossible for us to generate a stable REST API documentation. Is there a way to disable this behavior?

[avoinea]

@tisto True.

We have 2 options I can think of right now:

• Either patch portalTypeToSchemaName before the tests,
• or tweak the object _p_mtime

Another, elegant solution would be to convert portalTypeToSchemaName into an utility to be able to easily override it on need.

[tisto]

@avoinea could you look into fixing this in plone.restapi maybe? I don't really have the time for this right now and I ran into this again.