Data compatibility
Many customers have big implementations with lots of published data in the DD4T 2 JSON format. Purpose of data compatibility is to enable them to upgrade to DXA 2 without having to republish.
Examples of data as published by DD4T 2:
- Page: dd4t2-page.json
- Component presentation: dd4t2-cp.json
Possible combinations of used&published
DD4T published DD4T used in app DD4T & DXA Legacy applications | R2 published DD4T used Why really? | DD4T published R2 used in app New DXA 2 applications based on old data |
R2 published R2 used New DXA 2 applications | DD4T & R2 published R2 used New DXA 2 applications, data in migration | DD4T published DD4T & R2 used DD4T & DXA application in migration state |
DD4T & R2 published DD4T used DD4T & DXA Legacy applications, data in migration | R2 published DD4T & R2 used DD4T & DXA application in migration state | DD4T & R2 published DD4T & R2 used DD4T & DXA application in migration state |
Customers can never migrate existing applications in one step: it's way too much to republish and rewrite.
In case of new implementations, we would expect to use a new DXA from start, so it's not that important.
The most important is when customers have an existing application and can start partially rewriting and republishing data.
Model Service Provider and Converter
In order to achieve compatibility on a data level, we need to provide a solution that supports both models published and both models used in code. In DXA we don't care too much about a model since the final outcome is Entity/Page Model. We do care about model in DD4T though.
Looking at the table it becomes clear that we do need to be able to convert everything to everything.
For this we need:
- Model Service has a converter that accepts any model from broker database and converts it to any model requested. [Model Service side]
- Model Service Provider is called from existing builder pipeline and request appropriate model from Model Service. Should be delivered as pluggable dependency. [Webapp side]
- The provider in this part is actually the DD4T provider used by the Page/Component factories that will get data directly from the model service and request the data to be in DD4T form. This provider implementation should be available in both .NET and Java web apps with a facade available in DD4T namespace that will basically forward on requests to our new provider. This provider does nothing but request IPage, IComponent objects from the model service in DD4T form. This may mean the model service will have to convert R2 data model objects to DD4T json using the implementation provided by (1)
- The provider in this part is actually the DD4T provider used by the Page/Component factories that will get data directly from the model service and request the data to be in DD4T form. This provider implementation should be available in both .NET and Java web apps with a facade available in DD4T namespace that will basically forward on requests to our new provider. This provider does nothing but request IPage, IComponent objects from the model service in DD4T form. This may mean the model service will have to convert R2 data model objects to DD4T json using the implementation provided by (1)
- DXA drops support of DD4T on a webapp side. It always uses R2 model coming from Model Service (converted if needed). [Webapp side]
NB! This is a compatibility break and customers will need to rewrite their modules logic using Model Service Provider (#2). - DD4T applications use Model Service Provider (#2) and request DD4T models. [Webapp side]
- From the very beginning we deprecate all adapters for DD4T in documentation and code and strongly advise everyone to use R2. DD4T support will be dropped in DXA 3.