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

Reply via email to