Hi Gokul, On Thu, Jan 11, 2018 at 11:41 AM, Gokul Balakrishnan <[email protected]> wrote:
> Hi Sinthuja, > > Agree with your point. However, a new script will come with its own > complexities such as segregating permissions and preventing users from > retrieving names of tables not belonging to their tenant. > Anyhow, this is devops/advanced user related work, and not a general user related operation. Because inorder to get the encoded table name, the user should have the access to the database and knowing the table name/schema will not impose any security threat. So I don't think having shell script will reveal any additional security threat, given that the user who will be using this feature will be already having the db level access. > In addition, we already have a REST API operation for doing it the other > way (human-readable name to encoded name) already, hence the decision to > add this to the REST API too. > Hmm.. Ok.. Thanks, Sinthuja. Best, > > On 11 January 2018 at 11:17, Sinthuja Rajendran <[email protected]> wrote: > >> Hi Gokul, >> >> +1 to have a feature which returns the actual table name from the encoded >> table name that exists in the data storage. >> >> But IMHO, having REST API for this is not a correct way of doing, because >> REST APIs are intended to integrate this with external systems, and hence >> core analytics data operations need to be exposed via the REST API. But >> this feature is kind of a utility operation for debugging and not meant to >> be used by the users for normal table operations and also AFAIR it's >> applicable for RDBMS analytics data sources, not for others such as HBase. >> >> Therefore I propose, we'll have a utility shell script like a tool, which >> will take the encoded table name, and the data source type as params, and >> prompt the user-defined table name. >> >> Thanks, >> Sinthuja. >> >> On Thu, Jan 11, 2018 at 11:01 AM, Gokul Balakrishnan <[email protected]> >> wrote: >> >>> Hi, >>> >>> We have come across many cases where DAS tables stored in the EVENT or >>> PROCESSED stores (which have encoded names to comply with DB vendor >>> limitations) cannot be identified as representing which actual table just >>> by looking at them. This is a very useful functionality to have, especially >>> when debugging issues. >>> >>> In order to address this, I've implemented a DAS REST API operation >>> which will simply examine the calling user's tables and print out the name >>> of the actual table if a match is found. >>> >>> The usage will be as follows: >>> >>> GET (with auth) https://<DAS_HOST>:9443/analyt >>> ics/tables/<ENCODED_NAME>/actualName >>> >>> Example cURL command: >>> >>> curl -k -H "Authorization: Basic YWRtaW46YWRtaW4=" >>> https://localhost:9443/analytics/tables/ANX___7Lleafa0_/actualName >>> >>> We're planning to release this as a WUM update for DAS 3.1.0 and related >>> products. >>> >>> -- >>> Gokul Balakrishnan >>> Senior Software Engineer, >>> WSO2, Inc. http://wso2.com >>> M +94 77 5935 789 | +44 7563 570502 <+44%207563%20570502> >>> >>> >> >> >> -- >> *Sinthuja Rajendran* >> Senior Technical Lead >> WSO2, Inc.:http://wso2.com >> >> Blog: http://sinthu-rajan.blogspot.com/ >> Mobile: +94774273955 <+94%2077%20427%203955> >> >> >> > > > -- > Gokul Balakrishnan > Senior Software Engineer, > WSO2, Inc. http://wso2.com > M +94 77 5935 789 | +44 7563 570502 <+44%207563%20570502> > > -- *Sinthuja Rajendran* Senior Technical Lead WSO2, Inc.:http://wso2.com Blog: http://sinthu-rajan.blogspot.com/ Mobile: +94774273955
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
