powsybl / powsybl-network-store Goto Github PK

• Do you want to request a feature or report a bug?
  bug

• What is the current behavior?
  cloneVariant(overwrite=true) can change the variant num

• What is the expected behavior?
  variant Num shouldn't change

• What is the motivation / use case for changing the behavior?
  simplicity

• Do you want to request a feature or report a bug?
  feature

• What is the current behavior?
  Regulating terminals (for tap changers and genrators) are not yet implemented.

• What is the expected behavior?
  Regulating terminal should be supported.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  3 windings transformers, dangling lines, tie lines, LCC and VSC converters stations, HVDC lines and static var compensators are not yet implemented.

• What is the expected behavior?
  All equipments supported in IIDM API have to be implemented with the following priority

  • static var compensators
  • LCC and VSC converters stations,
  • HVDC lines
  • dangling lines
  • 3 windings transformers
  • tie lines
  • battery

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  bug

• What is the current behavior?
  the update mechanism always use the direct RestNetworkStoreClient, it doesn't take into account the preloading strategy. So updates are not batched

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Use the network store client and run a loadflow with preloading strategy = collection

• What is the expected behavior?
  All updates should be done in batch in the flush call

• What is the motivation / use case for changing the behavior?
  performance

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  In all adders and setters some validation have to be implemented like it is in iidm in memory implementation. In the current code this is no validation.

• What is the expected behavior?
  The expected behavior is the same as with in memory implementation of IIDM. To be consistent we have to share/reuse all validation code of in memory impl if IIDM. So before starting this issue, we have to refactor the code in powsybl core.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Remove methods are not implémentent. The tck
  Has about 90% test failures

• What is the motivation / use case for changing the behavior?
  Implementing the remove should greatly reduce the percentage of failing tests in the tck

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  When trying to generate a voltage level diagram from a persisted IIDM network I have the following logs:

Preloading strategy: NONE
Loading network resource /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18
network resource loaded in 8 ms
Loading voltage level resource /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1
voltage level resource loaded in 5 ms
Loading voltage level resource /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1
voltage level resource loaded in 5 ms
Building 'S1' graph...
Loading busbar section resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/busbar-sections
2 busbar section resources loaded in 4 ms
Loading generator resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/generators
2 generator resources loaded in 55 ms
Loading load resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/loads
2 load resources loaded in 4 ms
Loading shunt compensator resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/shunt-compensators
0 shunt compensator resources loaded in 5 ms
Loading static var compensator resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/static-var-compensators
0 static var compensator resources loaded in 6 ms
Loading VSC converter station resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/vsc-converter-stations
0 VSC converter station resources loaded in 4 ms
Loading LCC converter station resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/lcc-converter-stations
0 LCC converter station resources loaded in 4 ms
Loading 2 windings transformer resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/2-windings-transformers
0 2 windings transformer resources loaded in 8 ms
Loading 3 windings transformer resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/3-windings-transformers
0 3 windings transformer resources loaded in 8 ms
Loading line resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/lines
2 line resources loaded in 10 ms
Loading voltage level resource /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1
voltage level resource loaded in 4 ms
Loading voltage level resource /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S2
voltage level resource loaded in 6 ms
Loading voltage level resource /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1
voltage level resource loaded in 4 ms
Loading voltage level resource /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S2
voltage level resource loaded in 5 ms
Loading dangling line resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/dangling-lines
0 dangling line resources loaded in 6 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 5 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 6 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 7 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 7 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 8 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 5 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 7 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 5 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 7 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 5 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 5 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 8 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 5 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 8 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 6 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 9 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 6 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 7 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 5 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 6 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 9 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 6 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 6 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 5 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 11 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 11 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 6 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 8 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 7 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 10 ms
Loading switch resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/switches
15 switch resources loaded in 5 ms
31 nodes, 30 edges
Graph post-processor id 'PostProcessorMock' : Adding custom node in graph 'S1'
Loading voltage level resource /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1
voltage level resource loaded in 11 ms
Loading busbar section resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/busbar-sections
2 busbar section resources loaded in 4 ms
Loading generator resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/generators
2 generator resources loaded in 9 ms
Loading load resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/loads
2 load resources loaded in 5 ms
Loading shunt compensator resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/shunt-compensators
0 shunt compensator resources loaded in 10 ms
Loading VSC converter station resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/vsc-converter-stations
0 VSC converter station resources loaded in 8 ms
Loading LCC converter station resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/lcc-converter-stations
0 LCC converter station resources loaded in 4 ms
Loading static var compensator resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/static-var-compensators
0 static var compensator resources loaded in 4 ms
Loading 2 windings transformer resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/2-windings-transformers
0 2 windings transformer resources loaded in 9 ms
Loading 3 windings transformer resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/3-windings-transformers
0 3 windings transformer resources loaded in 9 ms
Loading dangling line resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/dangling-lines
0 dangling line resources loaded in 7 ms
Loading line resources /networks/97ba73b5-cc6d-41cd-862a-316719c7cf18/voltage-levels/S1/lines
2 line resources loaded in 7 ms

We can see that even if second level cache is enabled (so using PreloadingRestNetworkStoreClient) there is a lot of same data multiple reloading (like for switches).

• What is the expected behavior?
  When an equipment is loaded it should be put in the second level cache and next access should get equipment from the cache.

• What is the motivation / use case for changing the behavior?
  Improve performance and minimize database access.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Report a bug

• What is the current behavior?
  The test internalConnectionsFromCgmesTest() in powsybl-network-store/network-store-integration-test/src/test/java/com/powsybl/network/store/integration/NetworkStoreIT.java raises NullPointerException after implementation of terminal.isConnected(). So the test was temporarily ignored.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Unignore this test, run a maven build and the test will raise an error.

• What is the expected behavior?
  The test passes.

• Please tell us about your environment:

  • PowSyBl Version:3.4.0
  • OS Version: Fedora 29

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  In order to validate this IIDM new implementation we have to ensure that all unit tests developed in original IIDM impl also pass on new impl.

• What is the expected behavior?
  Some code refactoring have to be done on powsybl core side to be able to reuse unit tests. Then all these unit tests have to be integrated.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  bug

• What is the current behavior?
  Standalone RestNetworkStoreClient.getSome() doesn't work.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  $ mvn verify -Ptck -Dit.test=LccIT
  [ERROR] LccIT>AbstractLccTest.testBase:49 expected:<1> but was:<0>

• What is the expected behavior?
  test should work. It works if you use CachedNetworkStoreClient(RestNetworkStoreClient)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  LazyLoadingRestNetworkStoreClient does work well when loading an already stored network, but fails when it comes

  • to create a new network (not already flushed)
  • to create a new voltage level is an already created network

In both cases, we can see that flags fullyLoaded (both global one and per voltage level ones) are not set correctly. When a new network or voltage level is created it is empty for sure, but we have to consider them as fully loaded (event empty) => fully loaded means that client cache is consistent with what is on server side plus client buffer.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Create a new network or voltage level in an already existing network and check that when getting data this network or voltage level we don't go until the REST API but get it from the cache.
  Also when data are added to this network or voltage level but not flushed it should still be considered as fully loaded and be fully loaded from cache without REST call (which would be wrong as nothing will have been flushed)

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Only node/breaker networks could be imported.

• What is the expected behavior?
  We should be able to also import bus/breaker networks.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Design issue

• What is the current behavior?
  LazyLoadingRestNetworkStoreClient is available as a different pre loading strategy but it has nothing to do with preloading. It is all about caching. Preloading LAZY should be removed and already implemented COLLECTION preloading should be usable with LazyLoadingRestNetworkStoreClient caching.

Just to remind that preloading is the fact that we sometimes want to automatically load more data that asked. it has nothin to do with caching.
Only 3 preloading modes should be available: NONE and COLLECTION as today but also VOLTAGE_LEVEL_COLLECTION could be implemented.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Variant management is not yet implemented. The following code throws a TODO exception:

  network.getVariantManager();

• What is the expected behavior?
  We must implement variant management. Ideally variant could also be structural variant unlike original IIDM impl which only support state/control variable variants.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

OpenJDK 18 (may switch to 11), maven 3.8.4:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project powsybl-network-store-model: Fatal error compiling: java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in unnamed module @0x3c5095df) cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.processing to unnamed module @0x3c5095df -> [Help 1]

projectlombok/lombok#2681 ?

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  There is no way to update an IIDM object like:

Switch s = network.getSwitch("XXX");
s.setOpen(true);
networkStoreService.flush(network)

• What is the expected behavior?
  Update like in the previous example should work. Modified or dirty objects have to be memorized on client side and updated on server side by the flush.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Currently, the method Network::getIdentifiable(String) does not work when objects have not been pre-loaded by previous calls to other methods such as Network::getSubstation(String).

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Following test does not work in current version:

@Test
public void test() {
    UUID networkUUID;
    try (NetworkStoreService service = createNetworkStoreService()) {
        // import new network in the store
        Network network = ...; // creates a network that contains a substation of id "SUBSTATION_ID"
        service.flush(network);
        networkUUID = service.getNetworkUuid(network);
    }
    try (NetworkStoreService service = createNetworkStoreService()) {
        Network network = service.getNetwork(networkUUID);
        Identifiable identifiable = network.getIdentifiable("SUBSTATION_ID");
        assertNotNull(identifiable);
    }
}

However, following test passes:

@Test
public void test() {
    UUID networkUUID;
    try (NetworkStoreService service = createNetworkStoreService()) {
        // import new network in the store
        Network network = ...; // creates a network that contains a substation of id "SUBSTATION_ID"
        service.flush(network);
        networkUUID = service.getNetworkUuid(network);
    }
    try (NetworkStoreService service = createNetworkStoreService()) {
        Network network = service.getNetwork(networkUUID);
        Substation substation = network.getSubstation("SUBSTATION_ID");
        Identifiable identifiable = network.getIdentifiable("SUBSTATION_ID");
        assertNotNull(identifiable);
    }
}

• What is the expected behavior?
  Both tests should pass, Network::getIdentifiable(String) shoud be able to load the associated object without any pre-load.

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Cassandra materialized views are used for multiple indexing of equipment (per id and per voltage level id).

• What is the expected behavior?
  Cassandra materialized views seems to be marked as unstable in Cassandra 3 open source version and furthermore Cosmos DB Cassandra API does not support materialized views. So removing materialized views might be necessary.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Name of the network is used in primary key of the DB. There is no way to import a network 2 times, or 2 different networks with the same name.

• What is the expected behavior?
  A UUID should be used instead of the name.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  If name is not defined null is returned.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Create a substation without any name.

• What is the expected behavior?
  In the default IIDM impl when name is not set, the id is returned.

• What is the motivation / use case for changing the behavior?
  To be compliant with IIDM default impl.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  feature

• What is the current behavior?
  Xnode and MergedXnode use the previous hack (when no multi implementation is available) instead of wrapping the corrrect attribute

• What is the expected behavior?
  Wrap the correct attribute

• What is the motivation / use case for changing the behavior?
  robustness of network store

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Spring boot web service is implemented with classical Spring web framework..

• What is the expected behavior?
  Spring webflux could be used instead and would allow on client side to easily parallelize queries.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  bug

• What is the current behavior?
  MergedXnodeAdderImplNetworkStoreProvider in network-store-client

• What is the expected behavior?
  MergedXnodeAdderImplNetworkStoreProvider in network-store-iidm-impl

• What is the motivation / use case for changing the behavior?
  symmetry with other providers, offline mode without client

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Topology view are not implemented.

• What is the expected behavior?
  Topology view (bus/breaker view and bus view) have to be implemented. For performance reason calculated buses have to be stored in the DB so that when running a load flow we only have to load calculated buses and not restart from full topology (lot of switches).

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Some equipment are already supported but not all their attributes are taken into account.
  A no exhaustive list:

  • tap changer for transformers
  • reactive limits for generators
  • current limits for branches
  • regulating terminals

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  bug

• What is the current behavior?
  When visualizing a network using single-line-diagram, each time a new station is displayed, multiple requests are sent to get ALL switches of a voltage level from the database.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  Import a network in database. Start a powsybl-network-store-server. Start a network visualizer (for our test case, we use the ClientSubstationDiagramViewer of the pgs-network-store-demo). Each time the displayed substation is changed, we see in the server logs that a lot of requests are sent to retrieve all switches of the substation's voltage level(s).

• What is the expected behavior?
  It seems strange that this switches retrieval happens so many times.

• What is the motivation / use case for changing the behavior?
  To have better performances when creating the network graph (i.e. avoid to execute unnecessary retrieval requests)

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...
    Powsybl version: 3.1.0

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Network notifications are not implemented.

network.addListener(...)

• What is the expected behavior?
  Network notifications have to be implemented in a distributed way. So notification could be sent to a message broker and listener would be a broker consumer.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

The project network-store-model have lombok as dependency but the <scope>provided</scope> is missing, as said in their setup documentation.

The consequence is that other projects using it have lombok in production code in their dependencies.

• Do you want to request a feature or report a bug?
  feature

• What is the current behavior?
  Batteries are not yet supported.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  bug

• What is the current behavior?
  hard to use itools to do something with network-store

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  itools convert-network --input-file a.xiidm --output-file b.xiidm --output-format XIIDM

with the following config.yml

network:
    default-impl-name: NetworkStore

• What is the expected behavior?
  works

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)
  To fix it, I had to :

• use network-store-client, instead of network-store-iidm-impl because some extensions are in the client
• add a NetworkFactoryService class:

package com.powsybl.network.store.iidm.impl;
import com.google.auto.service.AutoService;
import com.powsybl.iidm.network.NetworkFactory;
import com.powsybl.iidm.network.NetworkFactoryService;

@AutoService(NetworkFactoryService.class)
public class NetworkFactoryServiceImpl implements NetworkFactoryService {

    @Override
    public String getName() {
        return "NetworkStore";
    }

    @Override
    public NetworkFactory createNetworkFactory() {
        return new NetworkFactoryImpl();
    }
}