-
Notifications
You must be signed in to change notification settings - Fork 960
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
v5 documents completely change how lifecycles work, not documented as a breaking change #2091
Comments
While this doesn't follow our required template I'm letting this one bypass our rules as a discussion. Is a topic for @alexandrebodin / @Marc-Roig / @innerdvations to get their thoughts |
Hello, Database lifecycles cannot be turned into document lifecycles as they are not operating on the same level and have a DB level API. Their API isn't broken as they are called on DB events correctly. We will definitely have to add a notice that with the new D&P feature more events on DB will get triggered 👍 That being said will need something else to know the higher level events that are happening on the document that you couldn't before (publish/unpublish etc) |
Yes, a notice would be very very welcome. Examples of things I do in lifecycles:
Update:
Delete:
Actually the current db lifecycles are pretty difficult to work with, as they get the "whatever it has been called with" I would way more prefer a lifecycles workflow that can tell me things like: "going to delete [{ }] because {}" and "delete has been called on [{ ... }] because {}". If document lifecycles to make this happen, it will make developing lifecycles so much easier (to understand). |
The documentService lifecycles will be more useful than the current db lifecycles as they are a few layers of abstraction higher. I was trying to do some testing of them today though (see the related bug report) and they are currently broken but I'm chatting with Alex and Marc internally about it. |
@derrickmehaffy you think will they land in 5.0.0? (so I can wait for it and forget about current lifecycles) |
Oh yeah they will, just have to squash out the bugs and get them documented (I did have to check and indeed they were not documented, likely because @pwizla was not aware they existed) |
I'm not sure what all is possible with them but from what I can see in the code they are wrapped around the documentService functions and have a |
We will add them in the beta docs soon but in the meantime you can do what is mentionned in strapi/strapi#19998 |
I'm going to move this over to the documentation since it's not really a "bug" per say but once we document the document service lifecycles we should probably classify it as a breaking change and show the difference between lifecycles and docsrv lifecycles |
@pwizla once you get the info to document the docsrv middlewares poke me and we can help write the breaking change info. |
@derrickmehaffy it's in here #2074 |
The various database lifecycle hooks triggered by the Document Service API methods are now documented here: https://docs-next.strapi.io/dev-docs/api/document-service/lifecycle-hooks |
(and Document Service API middlewares are documented here: https://docs-next.strapi.io/dev-docs/api/document-service/middlewares) |
in v4, a entry gets created as a draft (beforeCreate/afterCreate) and published (beforeUpdate/afterUpdate). All changes afterwards are beforeUpdate/afterUpdate
in v5 we have documents. Multiple entries per document. What happens now is:
create a document in draft (beforeCreate/afterCreate). Save the draft (beforeUpdate/afterUpdate). Publish the draft (a beforeUpdate/afterUpdate on the draft and a beforeCreate/afterCreate on the published entry).
When i now start changing the draft and publish it, the following sequence happens: beforeUpdate/afterUpdate on the draft. beforeDelete/afterDelete on the old published entry, beforeCreate/afterCreate on the new published entry.
This completely changes the way how lifecycles are working in v4. I now have way more create events, and even worse, I now have delete event which were not actual deletes of the (now..) document. All my current lifecycles need a complete rework, if this is the way forward. It is not documented in the breaking changes, which is really a big one for me, because I'm pretty sure people use lifecycles for a bunch of things that are really going wrong right now.
I really hope this is an oopsie and lifecycles would actually be triggered by events on the document, not on the entries of the document. Making lifecycles not a breaking change. Is it so?
The text was updated successfully, but these errors were encountered: