I guess I recognized some weird behavior in the packaging feature of DF 2.7, well, I don’t know if its supposed to work this way.
If I export a package with some DB service, without setting a password for the package, the DB credentials password in the json file is set to
If I export the package with a password set, the DB credentials password in the json file is set to
As stated in the wiki, the password should be the real one when exporting the package with a password as it gets encrypted.
Because of this, exporting DB services and related schemas will fail because the schemas cannot be applied without the right DB credentials.
Exporting 2 DB services with their schemas including virtual relationships to each other and reimporting them into another DF instance will fail.
The problem seems to be that the services get new IDs if they get imported into another DF instance, so the schemas, wich are using the service IDs to manage virtual relationships, will fail to import due to constraint violation.
Can anyone confirm this? Is this the expected behavior? Do I miss something in the usage of packaging?
I read about dumping the system DB and using it in the new DF instance but I thought that the packaging feature is the right solution that should be used here right?
To 1. : The packager get’s the services like they get returned by GET /system/service. This endpoint returns the service config with the DB password set to
To 3.: Exporting the schemes, extracting them, replacing the
"ref_service_id" : XX value with the new service ID and uploading the scheme json in the scheme editor works. Quiet hacky I guess.