[V5] Database

[Marc-Roig]

This PR introduces a draft version of the database layer changes for the V5 major release.

You can read it here.

[strapi-cla]

All committers have signed the CLA.

[derrickmehaffy]

I am quite worried that we won't be able to cover the use-cases properly for lifecycles. Within v4 lifecycles are the only means to directly impact both the content and admin APIs at the same time and we already have limitations around the relational data that doesn't exist within the lifecycles (not even to mention components and dynamic zones which don't have any lifecycle capability in v4 period).

Lifecycles IMO are quite important and something we should take a decision on before stable release and could prevent adoption and migration to v5 for those with more complex use-cases.

Plugin developers also do rely on our dynamic lifecycle injection in v4 quite often and many of our customers are actively using them as well for various reason, down to simple validation that we don't cover normally, all the way up to things like live updating data from external sources and data mirroring.

[derrickmehaffy]

For example, lifecycle hooks for components alone has 75 votes: https://feedback.strapi.io/feature-requests/p/lifecycle-hooks-for-components

[pwizla]

Minor point here, but on the following schema, shouldn't article_document_id from the article_author table link to document_id and not id in the article table, or did I misunderstand something? 🤔

[Marc-Roig]

@pwizla good catch! Updated the diagram

[Marc-Roig]

I am quite worried that we won't be able to cover the use-cases properly for lifecycles. Within v4 lifecycles are the only means to directly impact both the content and admin APIs at the same time and we already have limitations around the relational data that doesn't exist within the lifecycles (not even to mention components and dynamic zones which don't have any lifecycle capability in v4 period).

Lifecycles IMO are quite important and something we should take a decision on before stable release and could prevent adoption and migration to v5 for those with more complex use-cases.

Plugin developers also do rely on our dynamic lifecycle injection in v4 quite often and many of our customers are actively using them as well for various reason, down to simple validation that we don't cover normally, all the way up to things like live updating data from external sources and data mirroring.

@derrickmehaffy The idea is not to remove the database lifecycles, but to add new ones on the Service layer. Ones where you can hook to listen to document changes. The database lifecycles will still be maintained and what we could do is an evaluation of which issues there could be on db lifecycles when introducing documents.

At the moment I can not think of any, and we plan to internally use the db lifecycles too! Do you think we might want to elaborate on this more? @derrickmehaffy

[Boegie19]

@Marc-Roig Would the end of the entity-service layer not be better? since you could change the service its entity-service request or have entity-service decorators who change stuff. so the only place where you could do this the right way is the end of the entity-service or right of the end of the document service if the entity-service gets removed.

[Marc-Roig]

What benefit would you see of having this in the ES rather than on the database layer? Leaving lifecycles in DB is a must in V5 imo, as we aim to keep as much compatibility as possible.

[Boegie19]

@Marc-Roig

What benefit would you see of having this in the ES rather than on the database layer?

ES layer also knows about components and dynamic zones. so has more context. and this would mean if you blocked a request it would also block the components. and not only the highest level of the content-type.

Leaving lifecycles in DB is a must in V5 imo, as we aim to keep as much compatibility as possible.

Understandable I am not saying to remove them I am saying maby add a second layer of them.

[derrickmehaffy]

Do you think we might want to elaborate on this more? @derrickmehaffy

Absolutely we need to, both in the changes we will make and the differences to v4 comparatively. I think some of the issues around lifecycles is we don't use them enough ourselves so leveraging them for our purposes would be a good test point.

[derrickmehaffy]

What benefit would you see of having this in the ES rather than on the database layer? Leaving lifecycles in DB is a must in V5 imo, as we aim to keep as much compatibility as possible.

Agreed but I also agree with boegie here around implementing ES lifecycles too so each user can pick the right spot for their code to achieve what they want.

[Marc-Roig]

Agreed but I also agree with boegie here around implementing ES lifecycles too so each user can pick the right spot for their code to achieve what they want.

Yes! The current proposal is to create lifecycles on the Document Service layer, which also will be responsible to handle components. In my opinion, having lifecycles on that layer will make the DB lifecycles much less necessary for people (but we will keep them neverhteless)

[bglidwell]

Please keep and even further develop (by adding db support for things like cascade delete) the concept of "owned" records. ie. OneToMany OneToOne

These are critical structural distinctions that can easily be overlooked when pursuing versioning/i18n/etc

I am worried too much will be abstracted to the JS/TS side in strapi and the databases (and the data they store) will be useless outside the strapi application. Keep in mind several strapi devs are working on applications that store more than just marketing copy