Hi Sampath,
Please find a couple of queries related to this feature.
- How do revisions work with API versions? It would be good to define
the usage of each and how they differ.
- Can a given API version have multiple revisions? If yes,
- Are we allowing users to select a revision when an API version is
created?
- Are we going to list all revisions of a given API version in the
developer portal or we are going to set a single revision by default?
- Is revision_history_events going to be used to maintain a change log?
Thanks,
Himasha
On Wed, Nov 25, 2020 at 12:54 PM Chamila Adhikarinayake <[email protected]>
wrote:
>
>
> On Wed, Nov 25, 2020 at 10:28 AM Sampath Rajapakshe <[email protected]>
> wrote:
>
>> Hi All,
>>
>> We are planning to add the feature in $subject to the next API-M release
>> and this is to initiate a discussion on feature implementation design.
>>
>> The purpose of the feature from a high level point of view is as follows.
>>
>> API creator/publisher should be able to create an API revision(copy of
>> the current API state) from the current working copy of the API and should
>> be able to deploy that revision to multiple runtime gateway environments
>> and also if something breaks should be able to restore to a previous
>> revision.
>>
>> Therefore, the following functionalities will be provided to the API
>> creator/publisher.
>>
>> -
>>
>> Create/Delete revisions.
>> -
>>
>> Deploy revision to runtime gateway environments.
>> -
>>
>> Reset the current working copy to a previous revision.
>> -
>>
>> Can deploy a different revision to an already revision deployed
>> runtime gateway environment. Here, the previously deployed revision will
>> get un-deployed and newly selected revision will get deployed to that
>> particular environment. Users will be prompted for approval before this
>> task.
>> -
>>
>> Revisions are also immutable but once you revert back to a previous
>> revision, the user can work on top of that revision(which will be
>> considered as the working copy of API) and create a new revision and then
>> can deploy.
>>
>>
>> Once a revision is created we will be storing that particular API’s
>> registry artifacts to a new different path inside the registry.
>>
>> For example:
>> /system/governance/applicationdata/apis/<API_UUID>/revisions/<REVISION_ID>/
>>
>> Any possibility of storing this revision related data in the AM_DB
> instead of the registry? What are the benefits we get when we store it in
> the registry?
>
> As per the initial discussion, the proposed database structure to cater
>> above requirements is as follows,
>>
>>
>> Key Points are as follows,
>>
>>
>>
>> -
>>
>> ID and API_UUID are composite primary key for AM_REVISION table.
>>
>> Ex:
>>
>> ID= 1, API_UUID = 12345
>>
>> ID= 2, API_UUID = 12345
>>
>> ID=1, API_UUID = 98765
>>
>>
>> -
>>
>> Single API can have multiple revisions.
>> -
>>
>> One revision should be able to be deployed to multiple runtime
>> deployments.
>> -
>>
>> REVISION_UUID is the registry revisioned API artifacts ID.
>> -
>>
>> DISPLAY_ON_DEVPORTAL field is a flag to keep track of which runtime
>> deployment to be shown on the devportal.
>> -
>>
>> REVISION_ID field in AM_DEPLOYMENT_REVISION_MAPPING table refers to
>> the composite primary key(ID and API_UUID) in AM_REVISION table.
>> -
>>
>> The REVISION_ID field in the AM_REVISION_HISTORY_EVENTS table refers
>> to the composite primary key(ID and API_UUID) in the AM_REVISION table.
>> -
>>
>> One revision can have multiple related revision history events.
>>
>>
>> Also tables such as below which keep data related to API will be changed
>> accordingly to keep revision details by adding a revision id field.
>>
>> URL Mapping, AM_GRAPHQL_COMPLEXITY, AM_CERTIFICATE_METADATA,
>> AM_API_CLIENT_CERTIFICATE
>>
>> Appreciate your inputs on the current proposed database table structure.
>>
>> Thanks,
>>
>> Sampath
>>
>> --
>>
>> *Sampath Rajapakse* | Software Engineer | WSO2 Inc.
>>
>> +94717313761 | [email protected]
>>
>>
>>
>
> --
> Regards,
> Chamila Adhikarinayake
> WSO2, Inc.
> Mobile - +94712346437
> Email - [email protected]
> Blog - http://helpfromadhi.blogspot.com/
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
--
Himasha Guruge
Associate Lead Solutions Engineer - Solutions Architecture
WS*O2* *Inc.*
Mobile: +94 777459299
[email protected]
<http://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
