+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
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
