@Bhathiya Jayasekara <bhath...@wso2.com> yes, this is also an option. In reality though very few customers upload lots of additional docs. We could just rename DOC_META_DATA table to DOCS and store the docs in that table itself. So at the very minimum we have a swagger and ballerina definition per an API stored in the RESOURCES table.
Can we make a call on this soon? Implementation is getting delayed because of this. On Mon, 22 Oct 2018 at 21:08, Bhathiya Jayasekara <bhath...@wso2.com> wrote: > This looks ok. Btw, I was wondering if it's a good idea to have all files > (swaggers, wsdls, docs etc.) in a single table. Won't that make the table > grow faster and make querying slower? How about keeping a separate table > for this? Then we can have a foreign key as well. > > Thanks, > Bhathiya > > On Mon, Oct 22, 2018 at 2:57 PM Uvindra Dias Jayasinha <uvin...@wso2.com> > wrote: > >> +1, CONTENT is fine >> >> On Mon, 22 Oct 2018 at 14:45, Mushthaq Rumy <musht...@wso2.com> wrote: >> >>> Hi Uvindra, >>> >>> Please find the data types below >>> >>> *AM_API_DOC_META_DATA* >>> API_ID (This will be a foreign key referred to AM_API table) VARCHAR(255) >>> RESOURCE_ID VARCHAR(255) >>> DOC_CONTENT VARCHAR(1024) >>> >>> *AM_API_RESOURCES* >>> RESOURCE_NAME VARCHAR(255) >>> >>> And I think we can change it DOC_CONTENT to CONTENT . >>> WDYT? >>> >>> Thanks & Regards, >>> Mushthaq >>> >>> On Mon, Oct 22, 2018 at 2:35 PM Uvindra Dias Jayasinha <uvin...@wso2.com> >>> wrote: >>> >>>> HI Mushtaq, >>>> >>>> Can you provide the data types of the columns so that this is more >>>> clear? I believe that DOC_CONTENT should be a VARCHAR, in that case better >>>> to call it something like SHORT_CONTENT, since this communicates that it is >>>> meant to share relatively short text values such as URL and inline text. >>>> The name DOC_CONTENT is misleading and might suggest we can store larger >>>> documents in this column. >>>> >>>> On Mon, 22 Oct 2018 at 14:02, Mushthaq Rumy <musht...@wso2.com> wrote: >>>> >>>>> 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 <hars...@wso2.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha < >>>>>> uvin...@wso2.com> 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 <musht...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Adding @dev-wso2 <dev@wso2.org> >>>>>>>> >>>>>>>> On Thu, Oct 18, 2018 at 5:25 PM Nuwan Dias <nuw...@wso2.com> wrote: >>>>>>>> >>>>>>>>> Please discuss technical problems externally. >>>>>>>>> >>>>>>>>> On Thu, Oct 18, 2018 at 3:44 PM Mushthaq Rumy <musht...@wso2.com> >>>>>>>>> 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 : musht...@wso2.com >>>>>>>>>> WSO2, Inc.; http://wso2.com/ >>>>>>>>>> lean . enterprise . middleware. >>>>>>>>>> >>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Nuwan Dias* | Director | WSO2 Inc. >>>>>>>>> (m) +94 777 775 729 | (e) nuw...@wso2.com >>>>>>>>> [image: Signature.jpg] >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Mushthaq Rumy >>>>>>>> *Senior Software Engineer* >>>>>>>> Mobile : +94 (0) 779 492140 >>>>>>>> Email : musht...@wso2.com >>>>>>>> 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: hars...@wso2.coim >>>>>> Blog: harshcreationz.blogspot.com >>>>>> >>>>>> GET INTEGRATION AGILE >>>>>> Integration Agility for Digitally Driven Business >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mushthaq Rumy >>>>> *Senior Software Engineer* >>>>> Mobile : +94 (0) 779 492140 >>>>> Email : musht...@wso2.com >>>>> WSO2, Inc.; http://wso2.com/ >>>>> lean . enterprise . middleware. >>>>> >>>>> <http://wso2.com/signature> >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Uvindra >>>> >>>> Mobile: 777733962 >>>> >>> >>> >>> -- >>> Mushthaq Rumy >>> *Senior Software Engineer* >>> Mobile : +94 (0) 779 492140 >>> Email : musht...@wso2.com >>> WSO2, Inc.; http://wso2.com/ >>> lean . enterprise . middleware. >>> >>> <http://wso2.com/signature> >>> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> > > > -- > *Bhathiya Jayasekara* > *Technical Lead,* > *WSO2 inc., http://wso2.com <http://wso2.com>* > > *Phone: +94715478185* > *LinkedIn: http://www.linkedin.com/in/bhathiyaj > <http://www.linkedin.com/in/bhathiyaj>* > *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* > *Blog: http://movingaheadblog.blogspot.com > <http://movingaheadblog.blogspot.com/>* > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
