-
Notifications
You must be signed in to change notification settings - Fork 4
First steps with datacat: Developers
Example: Query classes The output includes all classes named "Lighting" including their parameters specified in nodes {}.
{
findSubjects(input: {query: "lighting"}) {
nodes {
id
createdBy
}
}
}
Example: Query classes and the groups they are assigned to.
The output includes all classes with the name "classname" including their parameters specified in nodes as well as the parent groups and their parameters specified in nodes {}.
{
findSubjects(input: {query: "classname"}) {
nodes {
name
collectedBy {
nodes {
relatingCollection {
name
}
}
}
}
}
}
Example: Query linked reference documents.
If no value is passed to the query in the query parameter, all catalog elements of the corresponding type, including the parameters specified in nodes {}, are output. The documentedBy parameter is used to output the linked reference document, if available.
{
findSubjects(input: {query:""}) {
nodes {
name
documentedBy {
nodes {
relatingDocument {
name
id
}
}
}
}
}
}
Example: Query units of a measure.
The output includes all units of measurement including their parameters specified in nodes, as well as the measures to which the unit of measurement is assigned.
{
findUnits(input: {query:""}) {
nodes {
name
assignedTo {
nodes {
relatingMeasure {
name
id
}
}
}
}
}
}
Example: Query the hierarchy
Output of the entire hierarchy possible. Filtering by ID, keywords or node type can be performed.
{
hierarchy(input: {rootNodeFilter: {catalogEntryTypeIn: Subject}}) {
nodes {
name
description
}
}
}
In the GraphiQL interface these further queries are possible:
query | return |
---|---|
hierarchy | Hierarchy |
findTags | Keywords |
findExternalDocuments | reference documents |
findBags | Subject Models |
findAssignsPropertyWithValues | Groups |
findSubjects | Classes |
findNests | Feature Groups |
findProperties | Characteristics |
findMeasures | Quantities |
findUnits | Units |
findValues | Values |
findAccounts | Users (see here) |
The following parameters (nodes) are possible with these queries:
parameters | return |
---|---|
id | Unique ID of the node |
name | Name of the node |
description | Description of the node |
tags {name, id} | Keywords of the node (here: name and ID of the keyword) |
names {language(displayLanguage)} | Available languages of the node |
created | Creation date |
createdBy | Name of the creator |
lastModified | Date of last modification |
lastModifiedBy | Name of the last editor |
versionId | Version ID |
versionDate | Date of version |
recordType | Node type |
__typename | Node type (according to ISO 12006-3) |
The following advanced filter criteria are possible for these queries: (For application: see above examples)
criterion | parameter | return |
---|---|---|
assignedTo | relatedMeasure | values with their related measure |
assignedTo | relatingMeasure | unit of measurement with their related measure |
assignedTo | relatingProperty | measure associated with a property |
assignedCollections | relatedCollections | child entities of type XtdCollection (property group) |
assignedProperties | relatedProperties | child entities of type XtdProperty (property) |
collectedBy | relatingCollection | parent entities |
documentedBy | relatingDocument | related reference documents to queried entity |
documents | relatedThings | related entities to queried reference document |
Create a new class
mutation {
createCatalogEntry(input: {
catalogEntryType: Subject
properties: {
id: 1234
version: {
versionId: "1.0"
versionDate: "13.12.2021"
}
names: {
id: 123
languageTag: "en"
value: "New class"
}
}
tags: 234763214
}) {
catalogEntry{__typename}
}
}
More GraphiQL commands are inside the Docs which can be found right above the output window of the GraphiQL interface!
Update a name
mutation {
updateName(input: {
catalogEntryId: 67574
name: {
translationId: 123
value: "New name"
}
}) {
catalogEntry{__typename}
}
}
More GraphiQL commands are inside the Docs which can be found right above the output window of the GraphiQL interface!
(not implemented yet)
To ensure catalog consistency, the check routines are available via the Check tab in the menu. They include the following queries:
Query | Check for |
---|---|
findModelWithoutGroup | models without associated group |
findGroupWithoutSubject | group without associated class |
findSubjectWithoutProp | classes without associated properties or property groups |
findPropGroupWithoutProp | property groups without associated properties |
findPropWithoutSubjectOrPropGroup | properties without associated classes or property group |
findMeasureWithoutProp | measures without associated property |
findUnitWithoutMeasure | units without associated measure |
findValueWithoutMeasure | values without associated measure |
findMultipleIDs | ID duplicates |
findMultipleNames | name duplicates |
findMissingDescription | missing description |
findMissingEnglishDescription | missing english description |
findMissingEnglishName | missing english name |
Example: findMultipleNames
The parameters for the output can be found in the table in the upper paragraph Queries.
{
findMultipleNames(input: {nodeTypeFilter: {}}) {
nodes {
name
id
description
}
}
}
This part refers to working with a local datacat instance for development. Prerequisite is the successful completion of the Guide to local installation of datacat.
The frontend, in the form of the datacat editor is based on the JavaScript framework React. Therefore, changes to the frontend are displayed directly in the browser after saving the customized file.
The backend is completely based on Java. It is recommended to make changes to the code using a source code editor, such as Visual Studio Code. Unlike JavaScript, in order for the changes to be visible via the browser, it is necessary to completely restart the corresponding Docker container. If only the backend itself is edited, it is necessary to delete the datacat container and remove the datacat_api image. Deleting the container can be done using the command:
$ docker compose down
If the image datacat_api was deleted manually, the container "datacat" can be restarted via the command:
$ docker-compose up -d
The db and mail containers do not usually affect further development. mail is used to manage email traffic for new user registration. This process is not functional in the local datacat environment. The db container concerns the database and will be dealt with in this tutorial.