Hey y’all - wondering what the process is like to request/submit a schema change?
Using the Okta plugin, and a little surprised that the group name isn’t a column, but a part of a JSON schema - happy to contribute this if people are open to it.
@tiny-beans You could either open an issue here or submit a pull request directly, which would be really awesome 
Hi! One easy way is to create another view on top. We try to make the tables look similar to the APIs and then let the users add any transformations on top.
Any guidance on the PR? Obviously new to the codebase, so I’m unsure of the pattern to follow. Do I need to create a new struct for the group type or somehow use the transformer package?
Code Reference
Created issue here → Issue #15175
I would suggest trying CREATE VIEW. This should be the simplest way to go. If you really want to productionize views and models inside the database, you can take a look at dbt-core, but if it’s just one thing, then just running
CREATE VIEW my_okta_groups ....
and selecting the fields that you need, you will be able to have a table with the data that you need without the need to build new plugins.
Why not the source table, though? This seems more confusing. Now I have to maintain a bunch of views and have users differentiate between the two.
It’s a best practice in the “modern data stack” to have views on top of other data, as it’s not possible to know all the use cases and transformations ahead of time. Usually, the process involves two steps: bringing the data and then adding more “sugar” on top to create easy-to-use views and data for specific use cases.
This is because right after we change something in the plugin, someone else will come and ask for it in a different format or to add another column. I’ll be happy to follow this issue and see if it’s a widespread issue among all users and if we may have done something wrong at the plugin level. However, from a quick look, it seems that this is the way that Okta APIs are returning the information.
We have a feature on our roadmap to make transformations before putting the data in for similar use cases, but we are not there yet.
Ok, I suppose that’s fair enough - re: roadmap, that means you’ll be supporting custom transforms on the way in? Or what will that look like?
Yeah, exactly! You will be able to write custom transformers in SQL on the way in, so tables can look different by adding columns, removing columns, and changing columns.
Neato! Is there any specific issue or feature request that you would like to track to follow the progress?