Service dialog serialization and performance

[skateman]

The current schema for dialogs is being pulled from multiple tables (Dialog, DialogTab, DialogGroup, DialogField) and its searialized into a single structure using classes inherited from Serializer. The relations between the tables are always 1:1, i.e. the fields are not shared among groups, groups among tabs and so on. The serialization process goes through all the relationships under a Dialog and merges the schema into a single structure. This process is highly ineffective as we have to do a ton of SQL joins when serializing a dialog with a lot of fields.

Most of the schema is static, except for the dynamically loaded tags and automate results (load_values_on_init) that are integrated into the serialization process. There is optional support for refreshing dialog fields, either with a button (show_refresh_button) or by changing a field that has explicit trigger (dialog_field_responders) to refresh other fields. As there is already a way to dynamically load information to an already serialized schema, I don't see a reason why we have to deal with dynamic data upon serialization at all. The static schema could be stored as a JSON (PostgreSQL has a special field for that) and passed directly to the dialog user through the API. All the initial dynamic information could be pulled in to the dialog user with a separate API request before rendering the dialog.

So let's to extract the dynamic information from the schema to use a similar logic to the triggered refresh that happens after rendering the dialog. After this we could simply store the serialized schema in the DB. This would improve the overall performance of the dialog user, the importing workflow and reduces the complexity of our models.

This would also allow us a transition to the React DDF schema which has a renderer for both PF3 and PF4 and with an editor implemented in itself. This could eventually replace our old angular implementation of the dialog editor and user, bringing us better maintainability on the UI side.

[Fryguy]

cc @tinaafitz

[martinpovolny]

The DDF WYSIWYG editor looks great. It would be cool to move forward with this. It would allow us to drop a good deal of old Angular code.

[martinpovolny]

I do not think that we need to start with remodeling things. The JSON schema can be treated as a case of the serialized dialog.

Might be easier to approach it that way.

But we absolutely need to start by removing the dynamic parts from the schema. W/o that we cannot move forward.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the traige process documentation.

[skateman]

@miq-bot rm_label stale

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

[miq-bot]

This issue has been automatically closed because it has not been updated for at least 3 months.

Feel free to reopen this issue if this issue is still valid.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.