Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Sub-entities are ignored #352

Open
grtjn opened this issue Mar 23, 2021 · 1 comment
Open

[BUG] Sub-entities are ignored #352

grtjn opened this issue Mar 23, 2021 · 1 comment

Comments

@grtjn
Copy link
Contributor

grtjn commented Mar 23, 2021

Describe the bug
If you have an entity model with structured properties, and the models for those sub-structures are contained inside the model itself, they are omitted from the Entity dropdown in the Pipes UI.

To Reproduce

  1. mlLoadModules this entity model:
{
	"info" : {
		"title" : "Test",
		"version" : "0.0.1",
		"baseUri" : "http://test.nl/datahub/entity",
		"description" : "Test case for Pipes bug report"
	},
	"definitions" : {
		"Test" : {
			"properties" : {
				"Prop1" : {
					"datatype" : "string"
				},
				"Nesting" : {
					"$ref": "#/definitions/NestingType"
				}
			}
		},
		"NestingType" : {
			"properties" : {
				"Prop2" : {
					"datatype" : "string"
				}
			}
		}
	}
}
  1. reload Pipes 2.0.5 ui
  2. look at Entity creation screen and check drop down. It lists Test, but not NestedType.

Expected behavior
Both Test and other embedded sub-types should all show up in drop down.

The values shows in the dropdown are influence by the backend service, which in turn runs the sparql code at this location:
https://github.com/marklogic-community/pipes/blob/master/ml-backend/src/main/ml-modules/services/vppBackendServices.sjs#L276

I suspect this code is meant to exclude external refs, but is effectively suppressing embedded types as well. I would recommend dropping the filter not exists clause entirely, and let the distinct dedupe where needed. This doesn't seem to cause any other side-effects when testing this locally.

Workaround

  • Put every type in separate file, but that creates a lot of clutter, and may have other undesireable sideeffects.
  • Use reverse source blocks, but that means manual work, which is undesireable too
@grtjn
Copy link
Contributor Author

grtjn commented Mar 23, 2021

Seems related to #291, which was closed without fixes..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant