[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.

[svrin]

I think it should be possible to have more than 2 publication states. Think about having diffrent environments where you want to publish a collection type.

[Marc-Roig]

Could you elaborate more on the example? What would be the new publication states in those cases?

One additional feature we had in mind is private drafts, but that's something that might come after having the v5 foundations ready.

[svrin]

Hi the setup in the case is like having multiple tenant and a collection that gets pubslihed to their different environments:

For example we have consultant that can have multiple web pages where they would be available.

consultant
| id | name | publication_state | publication_id |
| 1 | Karl Heinz | draft | 0 |
| 2 | Karl Heinz | live| 1 |
| 3 | Karl Heinz | live:immobilien | 1 |
| 4 | Karl Heinz | live:beratung | 1 |

Other use case we have are emails that can be sent (by mail) and published to a webpage, were we pin the mail publication state, but the live publication can be changed later (for example because of typos)

mail
| id | text | publication_state | publication_id |
| 1 | xxx | draft | 0 |
| 2 | xxx | mail | 1 |
| 3 | xxx | live | 1 |

[svrin]

pivot_publicationState should be pivot_publication_state. And i think the names should not be prefixed.

[svrin]

I think bidirectional should be included in v5, Otherwise parent/children relationsship of pages collection types are hard to implement in v5.

[Marc-Roig]

We are trying to work on this, and how to make them work with documents. We will keep you all updated. 🙏

[svrin]

There should be a method to have lifecycles on document level as well.

[Marc-Roig]

Indeed! We will have a document service (similar to the current entity service) with it's own lifecycles.

[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