You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of filtering and loading the data objects from the database it would be a big advantage if we could add the generic data index OpenSearch indices as data source. The performance with this approach would be much better.
A difficulty in this constellation are the data object models and field type specific GraphQL implementations. To simplify the migration it might be a good idea to directly fill the data object models out of the normalized index data. With this we could reuse the same models but without actually calling the database. Solving this problem could also be a big benefit for other similar constellations where its needed to serialize data objects outside of the default database tables (e.g. versions, data-sync bundle, ...).
The denormalize() methods of the field definition adapters should do a relatively good job in denormalizing the objects again out of the index data. Difficulties might occur regarding relations (relation data types, parent etc.). Maybe its possible to implement somehow a data provider approach so that it loads related items out of the database by default but out of the OpenSearch index if we setup/add a special data provider imlementation to the object.
The text was updated successfully, but these errors were encountered:
Improvement description
Instead of filtering and loading the data objects from the database it would be a big advantage if we could add the generic data index OpenSearch indices as data source. The performance with this approach would be much better.
A difficulty in this constellation are the data object models and field type specific GraphQL implementations. To simplify the migration it might be a good idea to directly fill the data object models out of the normalized index data. With this we could reuse the same models but without actually calling the database. Solving this problem could also be a big benefit for other similar constellations where its needed to serialize data objects outside of the default database tables (e.g. versions, data-sync bundle, ...).
The
denormalize()
methods of the field definition adapters should do a relatively good job in denormalizing the objects again out of the index data. Difficulties might occur regarding relations (relation data types, parent etc.). Maybe its possible to implement somehow a data provider approach so that it loads related items out of the database by default but out of the OpenSearch index if we setup/add a special data provider imlementation to the object.The text was updated successfully, but these errors were encountered: