Hi Sampath, Looks like both AM_DEPLOYMENT and AM_LABELS tables are serving the same purpose. Are we planning to keep the both?
If it's the working copy that'll be shown in the DevPortal, why is it needed to have the column DISPLAY_ON_DEVPORTAL? Even if we have to keep that column, shouldn't it come under AM_REVISION rather than AM_DEPLOYMENT_REVISION_MAPPING? On Wed, Nov 25, 2020 at 10:28 AM Sampath Rajapakshe <samp...@wso2.com> 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>/ > > 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 | samp...@wso2.com > > > -- *Amila De Silva* Software Architect | Associate Director, Engineering - WSO2 Inc. (m) +94 775119302 | (e) ami...@wso2.com <http://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
