Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

optimize temporary and permanent limits db writings and db reading #82

Merged
merged 66 commits into from
Jan 15, 2025

Conversation

EtienneLt
Copy link
Contributor

Please check if the PR fulfills these requirements

  • The commit message follows our guidelines
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem?

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change or deprecate an API?

  • Yes
  • No

If yes, please check if the following requirements are fulfilled

  • The Breaking Change or Deprecated label has been added
  • The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

Other information:

@EtienneLt EtienneLt self-assigned this Nov 21, 2024
Signed-off-by: Etienne LESOT <[email protected]>
Signed-off-by: Etienne LESOT <[email protected]>
Signed-off-by: Etienne LESOT <[email protected]>
Signed-off-by: Etienne LESOT <[email protected]>
@jonenst jonenst changed the title optimize temporary limits db writings and db reading optimize temporary and permanent limits db writings and db reading Nov 29, 2024
<customChange class="com.powsybl.network.store.server.migrations.PermanentLimitsMigration"/>
<customChange class="com.powsybl.network.store.server.migrations.TemporaryLimitsMigration"/>
<renameTable oldTableName="newpermanentlimits"
newTableName="permanentlimits"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before this, drop permanentlimit table.

And rename to permanentlimit

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rename to permanentlimits and it was permanentlimit before do you agree ? same for temporarylimits

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can keep permanentlimit I think. All table names use the singular

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed with Etienne L: we keep the plurial as one row of permanentLimits contains several permanent limits

<renameTable oldTableName="newpermanentlimits"
newTableName="permanentlimits"/>
<renameTable oldTableName="newtemporarylimits"
newTableName="temporarylimits"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

Signed-off-by: Etienne LESOT <[email protected]>
Signed-off-by: Etienne LESOT <[email protected]>
Signed-off-by: Etienne LESOT <[email protected]>
Signed-off-by: Etienne LESOT <[email protected]>
Signed-off-by: Etienne LESOT <[email protected]>
Signed-off-by: Etienne LESOT <[email protected]>
@@ -0,0 +1,22 @@
-- will be used in next deployment
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of doing the liquibase migration by doing a java change that just calls the same method as the one used for users

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. But the spring context is not available when the liquibase migration is executed and it makes things a bit more complicated to code. I built an "handmade" NetworkStoreRepository, not by Spring injection. To do so, I needed to build a javax.sql.DataSource and to retrieve the java.sql.Connection...

static final String SELECTED_OPERATIONAL_LIMITS_GROUP_ID_COLUMN = "selectedOperationalLimitsGroupId";
static final String TEMPORARY_LIMITS_TABLE = "newtemporarylimits";
static final String TEMPORARY_LIMITS = "temporarylimits";
static final String OLD_TEMPORARY_LIMITS = "temporarylimit";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need to find a better name than old because this code is going to stay if it goes in the liquibase changeset. Maybe "V211LimitMigration"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefix all code related to old tables with V211

Signed-off-by: Etienne Homer <[email protected]>
Signed-off-by: Etienne Homer <[email protected]>
Signed-off-by: Etienne Homer <[email protected]>
migrateV211Limits(repository, networkUuid, variantNum);
}
} catch (SQLException | DatabaseException e) {
LOGGER.error(e.getMessage(), e);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we shouldn't abort the migration on an error, migrate as much as possible ?

/**
* @author Etienne Homer <etienne.homer at rte-france.com>
*/
//Class to be deprecated when limits are fully migrated - should be after v2.13 deployment
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove comment, we keep this for the migration for eternity

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

<changeSet author="homereti" id="8428118131015-1">
<customChange class="com.powsybl.network.store.server.migration.V211LimitsMigration"/>
</changeSet>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add delete v211 tables here or even in the next version 2.14 ??

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a new changelog to be executed in 2.14

migrateV211Limits(repository, networkUuid, variantNum);
}
} catch (SQLException | DatabaseException e) {
LOGGER.error(e.getMessage(), e);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe need to be a bit smarter here. We should do the same exception handling as regular sql/xml changesets

Signed-off-by: Etienne Homer <[email protected]>
Signed-off-by: Etienne Homer <[email protected]>
Signed-off-by: Etienne Homer <[email protected]>
Signed-off-by: Etienne Homer <[email protected]>
@jonenst jonenst merged commit f8bd618 into main Jan 15, 2025
5 checks passed
@jonenst jonenst deleted the optimize-temporarylimits-in-db branch January 15, 2025 16:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants