In the latest release notes, it mentions the pdm endpoints are being deprecated and retired in November (https://www.gooddata.com/developers/cloud-native/doc/cloud/deploy-and-install/cloud/deprecated-features/pdm/) It also mentions changes are being made to the ldm endpoints. Which ldm endpoints are being updated/what changes are being made, etc.? We've noticed in the good data ui, when we validate/update an ldm based upon pdm changes, it still uses the deprecated endpoints

Hi Dave, It’s about the two endpoints which are marked as deprecated in our API documentation: https://www.gooddata.com/developers/cloud-native/doc/cloud/api-and-sdk/api/api_reference_all/#tag/PDM-Declarative-APIsbasically. In November, the plan is to enhance the LDM by incorporating the necessary information, eliminating the need for a separate PDM. The rollout will be done in a way that there will be a transition period when both of these ways (PDM vs extended LDM) will work and also the LDM will extend itself automatically with the information from existing PDM. This should be described in the upcoming release notes once the change is made.

Julius, will this cause a problem with data source changes? My only concern with this is making sure that the PDM being in the LDM doesn't introduce other issues that are based on environmental moves.

Hi Steve, thank you for expressing your concerns. They are very valid. Basically once it's announced in the release notes it will mark the beginning of the transition period, during which everything continues to work as is (with maybe certain things behaving differently on the backend). During this transition period, certain changes should be made to your solution to continue to work after the switch over (end of transition period). All changes are described here: https://www.gooddata.com/developers/cloud-native/doc/cloud/deploy-and-install/cloud/deprecated-features/pdm/ (which is basically what will be in the release notes). The changes should not affect front end or how the data sources are used, just the format of how the LDM/PDM information is stored within the layout. All changes are being throughly tested, so we are quite confident that it won't introduce any major issue (of course it's always possible that there is a corner case that might trigger some bug, but this is an important change for us, so all issues will be treated with the highest priority. PLEASE NOTE that the start of the transition period was postponed and should be announced in the next release.

Can you confirm we won’t see issues moving between environments? The pdm refresh is what we have run into making import through the api to not work optimally. So the inclusion of the pdm into ldm only concerns me that it will make importing into another environment impossible if the data source isn’t refreshed. Glad to see the change because it is a cumbersome issue now. However we know how to work around it now. No idea until the update if it will be an issue. Is there some pre production gooddata environment we could test with?

by moving between environments you mean exporting a declarative layout (or part of it) from one environment and importing it to another one?

Yes. We have a development workflow: dev->qa->prod for example. We have implemented tools to move analytical model and ldm from dev to qa for example. Today we know if there is a PDM update we go into qa, use the UI to refresh the data source/pdm and save. Then import.

yes, that's pretty common use case and as long as you use the same API on the both sides it will work (even the deprecated API for now).

Ok good to know