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
