Why are only Public dimensions supported for file upload of master data?

[ebajema1]

Could anybody explain why there is no option to populate a private dimension with master data from a flatfile or other source?

I have a particularly large private dimension to prepare, and I would like to do this independently of loading the transactional data. Copy-paste will not work due to the size, and so loading from a flatfile is the main way forwards.
Why should modellers be forced to change this to a public dimension just because the upload feature is not supported? What if I don't want this dimension to clutter up the master list of public dims?

Surely the only consideration behind whether a dimension is private or public should be whether you intend to re-use the same dimensions across multiple models or not. Why is this strange technical restriction here?

Many thanks

[david_stocker]

You can update master data in private dimensions during the course of loading fact data, but I suspect that this discussion is really about load jobs specific to master data. Loading master data without fact data into a private dimension would suggest that the users are planning (the use case where you might want to have unbooked data) on private dimensions and not only on public dimensions. My expectation would be that planning happens against public dimensions, but apparently people are doing it with private dimensions as well.

We do not have the infrastructure in place to load ONLY master data into a model's private dimensions, without also updating the fact data. We've also not updated the public dimension load jobs to use the new wrangler yet. As the product manager for that component, I'm annoyed every time I have to use the legacy wrangler to load data into a public dimension, because I nearly exclusively use WEL expressions to transform data. Loading master data is due for an update, but the wrangling team is busy with the data first modeling workflow for the new model.

Tl;Dr - Pratyush's answer is the workaround for the time being.

The import API is another beast. It actually bypasses most of the load job framework and only uses the mapping and validation infrastructure. The "local dimension only" is not a philosophical belief or deliberate design choice. It's just that the dev team is releasing import and export API as they build it.

[ebajema1]

Thanks david.stocker, that helps shed some light on the thinking behind the scenes.

It's interesting to hear you would expect planning to be only done against public dimensions, why is that?

Normally I'd expect there to be several models in a typical planning scenario, and while some of these models will share a lot of common dimensions, there are always dimensions which only appear in one model or another for a special purpose. It seems natural to model these one-off cases as local dimensions to avoid unnecessary confusion and clutter in the public dim list.

Would your approach just to be forget about the distinction and make everything a public dimension with no loss of functionality? Perhaps the impact of having more dimensions visible in the public list is not so terrible an outcome...

[JefB]

Exactly ebajema1. Maybe some reasons for using local dimension could also be:

1) Hiding sensitive master data from other developer / LOB's.
Maintaining this restriction through 'Roles' is technically possible but a huge pain to implement & monitor.

2) Security setup -> if a different DAC read/write access is needed for one particular model than was setup on the general (public) dimension used by other models, and using Roles (Data Privacy) is also not possible due to other restrictions.

3) Performance of import jobs/scheduling -> because you require an additional master data import job to run first.

david.stocker indeed, legacy wrangler on public dim wrangler is a pain, but I would say it's nearly impossible to wrangle some FX data into a currency table...