Hi All, We had an internal discussion and decided to do some modifications in the DB Schema related to API Docs (AM_API_RESOURCES and AM_API_DOC_META_DATA). We will be removing the foreign key constraint added to the AM_API_DOC_META_DATA table as it it has a primary key referred to the primary key of AM_API_RESOURCES which is not a good practice.
And the following columns will be added to the respective tables. *AM_API_DOC_META_DATA* API_ID (This will be a foreign key referred to AM_API table) RESOURCE_ID DOC_CONTENT *AM_API_RESOURCES* RESOURCE_NAME So the content of INLINE and URL of API documents will be saved in *AM_API_DOC_META_DATA (*DOC_CONTENT column*) *and content of FILE of API documents will be saved in *AM_API_RESOURCES *which will have a reference in *AM_API_DOC_META_DATA (*RESOURCE_ID column*)*. Thanks & Regards, Mushthaq On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara <[email protected]> wrote: > > > On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha <[email protected]> > wrote: > >> Here is my take on this. When I originally designed the schema I wasn't >> taking into consideration any of the practical implications associated with >> API resources being saved and retrieved at DB level. But now that we are at >> implementation stage some of these implications are much more clearer now. >> >> The AM_API_RESOURCES is a generic API resource table(For storing all file >> based resources associated with APIs). It will be storing the Swagger file, >> Ballerina file and documentation associated with the API. >> >> The AM_API_DOC_META_DATA table is specialized to store additional meta >> data only associated with documentation. >> >> Practically we need to do two calls for document uploads and adding meta >> data because we are dealing with two different content >> types(application/json for meta data and multipart/form-data for the file). >> >> All files have a name associated with them so it makes sense to have the >> file name in the AM_API_RESOURCES table. I don't think its a good idea to >> have a NULL value in a column that we are going to update later, this could >> lead to all kinds of complications that we will need to handle at code >> level. So its better to have the file name in AM_API_RESOURCES where we can >> ensure that we always have a valid name at the time of upload. It is also >> very easy for us to enforce that a file name for a given type does not get >> duplicated with a table level constraint if we go with this option. >> >> Joining between two tables like this in case we need to get the file name >> is trivial so I don't think we should let that affect us coming up with the >> best possible solution. >> > +1 it's a not good practice to add record which will update from null to > some value cause of update going for another table. > >> >> So Im +1 for option 2. WDYT? >> >> On Thu, 18 Oct 2018 at 17:31, Mushthaq Rumy <[email protected]> wrote: >> >>> Adding @dev-wso2 <[email protected]> >>> >>> On Thu, Oct 18, 2018 at 5:25 PM Nuwan Dias <[email protected]> wrote: >>> >>>> Please discuss technical problems externally. >>>> >>>> On Thu, Oct 18, 2018 at 3:44 PM Mushthaq Rumy <[email protected]> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> While I was implementing the view page for API document (File) I came >>>>> across an issue where we get the file name as null when using the >>>>> micro-service to get the content of the the API document. >>>>> While analyzing, when adding a file as an API document, I found out >>>>> that first we save only the doc metadata and then we save the file >>>>> content >>>>> using a second call. >>>>> >>>>> After analyzing the DB scripts I figured out that the fileName is >>>>> stored in AM_API_DOC_META_DATA table and the content is stored in >>>>> AM_API_RESOURCES. So during the first call we do not have the file name >>>>> and >>>>> it is saved as null. During the second call the fileName is passed to the >>>>> micro-service but it is not stored anywhere. Hence, the fileName is null >>>>> when we get the content of the file. So to solve this issue, I thought of >>>>> two solutions. >>>>> >>>>> 1. During the second call while adding a file document for API as we >>>>> get the FileName to the micro-service we can retrieve the document >>>>> metadata >>>>> using the documentId and update the fileName apart from saving the >>>>> content. >>>>> Hence, it will be available when retrieving the content. >>>>> >>>>> 2. We can change the fileName field from AM_API_DOC_META_DATA to >>>>> AM_API_RESOURCES as the content of the document is stored in this table. >>>>> And while saving the content we can save it with the fileName. Hence, it >>>>> will be available when retrieving the content. >>>>> >>>>> IMO as option 1 will have more DB calls, option 2 would be the >>>>> preferred solution. >>>>> >>>>> Appreciate your valuable inputs. >>>>> >>>>> Thanks & Regards, >>>>> Mushthaq >>>>> -- >>>>> Mushthaq Rumy >>>>> *Senior Software Engineer* >>>>> Mobile : +94 (0) 779 492140 >>>>> Email : [email protected] >>>>> WSO2, Inc.; http://wso2.com/ >>>>> lean . enterprise . middleware. >>>>> >>>>> <http://wso2.com/signature> >>>>> >>>> >>>> >>>> -- >>>> *Nuwan Dias* | Director | WSO2 Inc. >>>> (m) +94 777 775 729 | (e) [email protected] >>>> [image: Signature.jpg] >>>> >>> >>> >>> -- >>> Mushthaq Rumy >>> *Senior Software Engineer* >>> Mobile : +94 (0) 779 492140 >>> Email : [email protected] >>> WSO2, Inc.; http://wso2.com/ >>> lean . enterprise . middleware. >>> >>> <http://wso2.com/signature> >>> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> > > > -- > > *Harsha Kumara* > > Associate Technical Lead, WSO2 Inc. > Mobile: +94775505618 > Email: [email protected] > Blog: harshcreationz.blogspot.com > > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business > -- Mushthaq Rumy *Senior Software Engineer* Mobile : +94 (0) 779 492140 Email : [email protected] WSO2, Inc.; http://wso2.com/ lean . enterprise . middleware. <http://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
