Is there any upgrade guideline that is being published for us to upgrade our production plugins to ACSB 3.0.0. We attempted an upgrade recently but had to rollback.
I see that public_key column was dropped in commit: 187026a
and
authentication and cloud_id columns were added in commit: 5fe4fdb . This is failing the startup of our plugin in production environments.
@SumeetSingh please see the thread below for links to more details. Also see the Jira issues themselves.
db.changelog-master.yaml contains changes to the database schema for AtlassianHostRepository. If you are not using Spring Data JPA, you may need to apply corresponding changes.
Can you describe the problem you are facing in more detail?
As you suspected, the startup of application is failing (JPA validation failures) due to missing column.
Although we are using Spring Data JPA, but since we have our own table schemas to manage as well, we are maintaining a separate (liquibase based) mechanism for managing database schema upgrades.
As you pointed out, we are planning to make the required column addition and removal. The only thing we are wondering, what would be the impact of removing public_key column.
I will try to search for documentation on semantic meaning and usage of newly inserted columns. (cloud_id and authentication)
We are not currently in process of migrating the application to Forge. So did not dig too deep into posts and articles related to Connect to Forge migration. Is that something that is going to become a requirement in near future ? Are Connect apps being completely phased out ?
Hi @SumeetSingh , the cloud_id and authentication are for Connect-on-Forge apps only and they are for allowing apps to authenticate using OAuth 2.0. There is no documentation for that at this point except the code comment, we will schedule this work of adding more documentations around this.
There seems to be an issue due to the mismatch of the expected database type (varchar as specified in database migration) for authentication field/column and effective one when using jpa+hibernate, which uses ordinal representation for enums, if not specified otherwise https://ecosystem.atlassian.net/browse/ACSPRING-175
@epehrson can someone look into this?
It’s not just a validation error and it possibly can lead to inconsistend data types in atlassian_host tables for library consumers.
Hi @lexek-92, thank you for raising the issue with us and thanks for your patience!
Our team has created a bug ticket in our backlog, we will schedule an investigation and fix next sprint.