Export bundle without top-level properties attribute

[ecelen-minvws]

Description:
Is it possible to export a bundle without the top-level properties attribute?

Use case:
I want to commit exported bundles to Git. The properties section appears to contain metadata, and I would prefer to exclude it to keep the bundle clean and avoid unnecessary diffs.

Current behavior:
When importing a bundle that contains the top-level properties attribute, the import command logs the following warning twice:
[warn] unknown entities, properties

If I manually remove the top-level properties attribute before importing, the warning still appears, but only once.

Questions:

• Why does the import process log [warn] unknown entities, properties?
• Why does it appear twice when properties is present?
• Is there a supported way to export a bundle without the top-level properties section?

Environment:

graphman client v2.0.9
schema v11.1.2
supported schema(s): [v11.2.0, v11.1.3, v11.1.2, v11.1.1]
supported extension(s): [pre-request, post-export, pre-import, multiline-text-diff, policy-code-validator]

[graju256]

@ecelen-minvws This warning can be safely ignored. But, we will get this corrected in next release.

Besides this, it is true that properties section of the bundle essentials designed to hold extra information like, metadata, default action, mappings, etc. This section is optional for standard mutation operation (i.e., install, where the defaultAction is NEW_OR_UPDATE). If this mutation needs to be customized, we must include properties with the required customizations. Otherwise, it is OK to remove the properties section from the bundle.

[muemi03]

FYI: For sure , not recommended !
We've added a little tweak to modules/graphman-operation-explode.js
Instead of line 240: if (bundle.properties) {
Do a : if (bundle.properties && !options.noProperties) {
Doing a "graphman explode --input ... --options.noProperties"
would avoid a "bundle-properties.json" file, when doing the explode, as it sometimes disturbs in a repo.
You could even add it to your graphman.configuration for defaulting this behavior:

{
    ...
    "options": {
        ...,
        "noProperties": true
    }
}

At least this is working well for our purposes.
But for sure, you potentially loose all your activity mappings, as Raju pointed out.
And changing source-code is never a good idea for most of us :)

[ecelen-minvws]

@ecelen-minvws This warning can be safely ignored. But, we will get this corrected in next release.

Besides this, it is true that properties section of the bundle essentials designed to hold extra information like, metadata, default action, mappings, etc. This section is optional for standard mutation operation (i.e., install, where the defaultAction is NEW_OR_UPDATE). If this mutation needs to be customized, we must include properties with the required customizations. Otherwise, it is OK to remove the properties section from the bundle.

@graju256

Thank you for the clarification, and it’s good to hear that the warning will be corrected in the next release.

One question that is still open:

Is there a supported way to export a bundle without the top-level properties section, or would this require using the post-export extension?

[ecelen-minvws]

FYI: For sure , not recommended ! We've added a little tweak to modules/graphman-operation-explode.js Instead of line 240: if (bundle.properties) { Do a : if (bundle.properties && !options.noProperties) { Doing a "graphman explode --input ... --options.noProperties" would avoid a "bundle-properties.json" file, when doing the explode, as it sometimes disturbs in a repo. You could even add it to your graphman.configuration for defaulting this behavior:

{
    ...
    "options": {
        ...,
        "noProperties": true
    }
}

At least this is working well for our purposes. But for sure, you potentially loose all your activity mappings, as Raju pointed out. And changing source-code is never a good idea for most of us :)

@muemi03 Thank you, but I'd rather not change the source code :)

[graju256]

@ecelen-minvws Let me see if this is feasible to provide an option for not including the properties section.

[ecelen-minvws]

@ecelen-minvws Let me see if this is feasible to provide an option for not including the properties section.

That would be great!