Add backward compatibility for CgmesControlAreas extension deserialization #3298
Conversation
…tension Signed-off-by: Olivier Perrin <[email protected]>
Signed-off-by: Olivier Perrin <[email protected]>
Signed-off-by: Olivier Perrin <[email protected]>
...ensions/src/main/java/com/powsybl/cgmes/extensions/compatibility/CgmesControlAreasSerDe.java
Show resolved
Hide resolved
|
I have tested the backward compatibility using a real world test case and it works perfectly. |
Signed-off-by: Olivier Perrin <[email protected]>
|
|
||
| @Override | ||
| public void write(DummyExt extension, SerializerContext context) { | ||
| throw new UnsupportedOperationException("Backward writing compatibility is not yet supported."); |
There was a problem hiding this comment.
yet means we'll do it one day, will we? Besides shouldn't this rather be something like "cannot happen"? We're here with a DummyExt which is never created, and cannot be created.
| * @author Olivier Perrin {@literal <olivier.perrin at rte-france.com>} | ||
| */ | ||
| @AutoService(ExtensionSerDe.class) | ||
| public class CgmesControlAreasSerDe extends AbstractVersionableNetworkExtensionSerDe<Network, CgmesControlAreasSerDe.DummyExt> { |
There was a problem hiding this comment.
why not using AbstractExtensionSerDe instead of AbstractVersionableNetworkExtensionSerDe? I don't get why we need the versionable part as there's only one the 1.0 version.
There was a problem hiding this comment.
Yes you're right, there's no need for the versionable management.
I will replace it.
There was a problem hiding this comment.
Hum no, sorry. I wanted to limit the extension to the IIDM versions <= 1.13.
The extension should not be accepted for the newer versions of IIDM.
There was a problem hiding this comment.
Hmm, there's no harm in accepting it for versions > 1.13, even though it will never occur, as there won't be any way to get a 1.14 xiidm with such an extension.
Signed-off-by: Olivier Perrin <[email protected]>
Signed-off-by: Olivier Perrin <[email protected]>
|
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
No
What kind of change does this PR introduce?
Feature
Does this PR introduce a new Powsybl Action implying to be implemented in simulators or pypowsybl?
What is the current behavior?
#3149 removes the
CgmesControlAreasin favor of the usage of IIDMAreas, but the backward compatibility with the extension is not supported. Therefore when importing an old generated IIDM network containing the extension, the content of this extension is not loaded and no CGMES areas are created.What is the new behavior (if this is a feature change)?
With this PR, the serialized extension is read and IIDM
Areas are created for eachCgmesControlAreaof the extension.Note that when reading a CgmesControlArea from the serialized extension, if an
Areawith the same ID is already present on the network, the CgmesControlArea is skipped.Does this PR introduce a breaking change or deprecate an API?
If yes, please check if the following requirements are fulfilled
What changes might users need to make in their application due to this PR? (migration steps)
Other information:
For now, only the reading compatibility is supported, because it is not trivial to implement the writing compatibility: there's no extension corresponding to the CGMES areas on the network, so the extension serialization mechanism could not be used directly