Hi! I’m struggling with using

tablePrefix

when scanning PDM and/or LDM. My demo SCHEMA has 3 tables

campaign_records
campaign_records_activities
contacts

If I run

## Scan Data Model
curl -X "POST" "<http://localhost:3000/api/actions/dataSources/billing-snowflake-ds/scan>" \
     -H 'Content-Type: application/json' \
     -H 'Authorization: Bearer YWRtaW46Ym9vdHN0cmFwOmFkbWluMTIz' \
     -d $'{
  "separator": "__",
  "scanTables": true,
  "scanViews": true,
  "schemata": [],
  "viewPrefix": "",
  "tablePrefix": ""
}'

I get proper

pdm

(see here https://gist.github.com/padak/1a74e847c9e42f81b26a4b9044aab55b). If I add

tablePrefix

and run

## Scan Data Model
curl -X "POST" "<http://localhost:3000/api/actions/dataSources/billing-snowflake-ds/scan>" \
     -H 'Content-Type: application/json' \
     -H 'Authorization: Bearer YWRtaW46Ym9vdHN0cmFwOmFkbWluMTIz' \
     -d $'{
  "separator": "__",
  "scanTables": true,
  "scanViews": true,
  "schemata": [],
  "viewPrefix": "",
  "tablePrefix": "contacts"
}'

I get this result:

{
  "pdm": {
    "tables": []
  },
  "warnings": []
}

What I expect to get is just a

pdm

definition of

contacts

table. My goal is to scan any data in the specific SCHEMA, but allow users to interact only with one table - which I’ll achieve by limiting

ldm

associated with GD Workspace. Should the prefix definition work this way?

table/viewPrefix is intended to be used differently. It is automatically cut off from table name to create dataset name. You should prefix set of tables with this prefix and use also the separator, e.g.

gd__contacts

. If you want to allow users to interact with only one table (or generally subset of tables) , I recommend to provide them worspaces, where you create only single dataset on top of single table and then setup permissions appropriately (will be available starting from 1.7, which is going to be released before end of this month). If you have more feedback / thoughts in this area, I am free to join a call with you or go to lunch 😉

@Jan Soubusta got it! so implementing permissions by changing scope in PDM is not the recommended approach - you rather push us to make the db schema with i.e. VIEW, pointing to elsewhere and in the gooddata.cn define new data-source having access to the view? we do have a usage concept in our minds, which might be influenced by wrong expectations - so jumping on a short call would be appreciated! our internal hackathon is over and thanks to that experience, we might want to make “usage reporting” for our users in GD.cn… but i.e. we’re not sure if classical MUFs are available…

let's sync f2f, then I will document the outcome here 😉