Hi Uvindra

How do we paginate searched and sorted data, searching and sorting will be
hard without using a DBMSs support ? And I think we can come up with
simpler solutions for the points you have mention and still stick with a
DBMS.

On Wed, Nov 16, 2016 at 10:34 AM, Uvindra Dias Jayasinha <[email protected]>
wrote:

>
>>> 1. Display only the latest version of a given published API by the API
>>> Store - Since the version is a VARCHAR column we cannot assume it is
>>> numerical so its not straightforward to find the latest version of a given
>>> API via SQL.
>>>
>>
As a solution we can introduce a numeric version column which will be
updated when the API is saved based on the version string given. With that
update cost is high retrieve cost is low.


>
>>> 2. Validate an APIs roles against a given users roles to validate
>>> eligibility to view the API - In situations where users have a large number
>>> of roles assigned to them we will need to pass all these roles in the WHERE
>>> clause of the SELECT statement when filtering the result set further
>>> complicating statement.
>>>
>>
If the visibility is only depend on roles I guess it is a straight forward
thing to implement with SQL. When you mention large number of roles what
would be a rough amount we have to expect and in which scenarios ?


>
>>> Given that in the C5 tenancy model each tenant will have there own DB
>>> instance, data numbers will be quite low. For example it will be unusual to
>>> have a 1000 APIs in the DB. So in this scenario its a lot easier to read
>>> the entire result set into memory at the back end and then paginate what is
>>> returned to the caller at Java level along with doing permission checks.
>>> the advantage of this is,
>>>
>>
Even though its unusual there are existing users with 700+ APIs so we
should be able to support it.


> 1. Minimise the need to maintain vendor specific SQL for pagination
>>> 2. Simplifies SQL statements
>>>
>>
If the above is a big problem we can see the possibility of using a
in-memory db (ie h2). Then we only have to maintain SQL queries only for
that. I guess that will be lot efficient than processing raw data using
Java. We can load the data to in-memory db on-demand.

Thanks & Regards
Jo








-- 
>> With regards,
>> *Manu*ranga Perera.
>>
>> phone : 071 7 70 20 50
>> mail : [email protected]
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 777733962
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

-- 
*Joseph Fonseka*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 772 512 430
skype: jpfonseka

* <http://lk.linkedin.com/in/rumeshbandara>*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to