On Tue, Oct 23, 2018 at 10:07 AM Uvindra Dias Jayasinha
wrote:
> @Bhathiya Jayasekara
> 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
+1 for having all API doc related data in a single table and rename the
table as DOCS.
Thanks & Regards,
Mushthaq
On Tue, Oct 23, 2018 at 10:07 AM Uvindra Dias Jayasinha
wrote:
> @Bhathiya Jayasekara
> yes, this is also an option. In reality though very few customers upload
> lots of
@Bhathiya Jayasekara
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
Hi Johann,
Please note that there are some modifications to be done on this. Also, if
the placement is not matching here, it can go under the "Configure" tab
(since the overall process is to configure SPs and IdPs).
I think that your point is fair about avoiding InCommon logo and I will
consider
Hi team,
I'm using a custom federated authenticator, which authenticates the user
against 3rd party API. What I would like to know is that, whether we will
be able to assign roles to it without provisioning the user to the user
store.
Thanks,
Rajith
--
*Rajith Siriwardana*
WSO2 Inc. |
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,
Hi Aman,
Please find the sample below.
Thanks
On Mon, Oct 22, 2018 at 2:59 PM Aman Singh wrote:
> Hi Shakila,
>
> When I try to get properties which I have stored in gov/registry in XML ia
> below code I am successfully able to do so:-
>
>
> expression="get-property('registry',
+1, CONTENT is fine
On Mon, 22 Oct 2018 at 14:45, Mushthaq Rumy 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)
>
>
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 .
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
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
Created [1] https://github.com/wso2/product-apim/issues/3880 to track the
issue.
[1] https://github.com/wso2/product-apim/issues/3880
Thanks
Godwin
On Sun, Oct 21, 2018 at 3:53 PM Godwin Shrimal wrote:
> Hi Tharindu,
>
> Yes. This is a distributed setup and it is having correct configurations
12 matches
Mail list logo
