The constructor of the ITAB-Container will "normalize" the format of the internal table.
That means:
Any given table will be converted into TYPE STANDARD TABLE ... WITH NON-UNIQUE DEFAULT KEY
Components, that cannot be rendered by an ALV-Grid (e.g. object references) will be removed from the line type
The line type of the normalized table will be a structure in any case - if the source table used a data element as the line type, it will be converted into a structure having exactly one field of that type
All these optimizations are needed to achieve compatibility with the ALV Grid, that will render the data later or to avoid wasting space on the database. However this should not happen in the constructor, since the container might still be irrelevant, if the log level is too low - so we might be doing some heavy lifting for nothing!
The normalization should be moved to the serialize-method. That would give us a lightweight constructor while preserving all advantages of the table format normalization.
The constructor of the ITAB-Container will "normalize" the format of the internal table.
That means:
All these optimizations are needed to achieve compatibility with the ALV Grid, that will render the data later or to avoid wasting space on the database. However this should not happen in the constructor, since the container might still be irrelevant, if the log level is too low - so we might be doing some heavy lifting for nothing!
The normalization should be moved to the serialize-method. That would give us a lightweight constructor while preserving all advantages of the table format normalization.