If I have view B which implements view A, in the definition of view B do I need to list the properties (e.g. container mappings) that are “inherited” from A? I noticed that if I don’t list them, this works fine the first time when view B is created (I can see the inherited properties automatically included), but if I try to update view B (even if nothing changes) the call fails saying that there is a change in the property list and the version needs to be changed. I’m assuming this is because the inherited properties are missing from the definition. Is this behavior by design and I have to explicitly list the properties, or would it be considered a defect?
More of a design question: only interfaces are allowed after the implements keyword, so you have to know what types you plan to extend beforehand, but this is not always possible or reliable. Since interfaces also produce views, I am tempted to make everything an interface, but are there any downsides?
Using transformations to create/update data can be cumbersome especially for complex FDM models. I understand there are plans to generate APIs from models, but are there any alternatives in the short term, such as implementing GraphQL mutations? Are the APIs used by transformations internal to CDF?
I’m experimenting with filter nodes https://pr-ark-codegen-1646.specs.preview.cogniteapp.com/v1.json.html#tag/Instances-(New)/operation/advancedListInstance using a payload like:{ "includeTyping": false, "sources": [ { "source": { "type": "view", "space": "jca-domain", "externalId": "Facility", "version": "0_3" } } ], "instanceType": "view"}It seems to return entities not of the type of the given source (Facility/0_3). For example it returns Equipment/0_3 entities. Is this the expected behavior and do I have to separately filter for view type? If so how do I do that? Thanks.
Hi, I am trying to use the Data Modeling API (https://pr-ark-codegen-1646.specs.preview.cogniteapp.com/v1.json.html#tag/Instances-(New)/operation/applyNodeAndEdges) to create instances of Views I have defined, including a reference property from one view to another. The reference property in the view looks like this: "facility": { "type": { "space": "jca-domain", "externalId": "EquipmentFacility" }, "source": { "type": "view", "space": "jca-domain", "externalId": "Facility", "version": "0_1" }, "direction": "outwards" }I’m not including the whole definition as it is kind of lengthy, but basically there is a Facility view and an Equipment view, and the above property is on the Equipment so I can link it to a Facility. I am able
When creating a transform into an FDM type, it is necessary to provide the externalId of the instance. Does the value of externalId need to be unique across all instances of all types in the model or only across instances of the given type?
As we develop richer models supporting a greater variety of workflows, we have started asking questions about model maintenance and modularization. Decomposing large models into sub-models that have low coupling seems attractive, but would require some type of referential support across models. Is Cognite considering such a feature, or how do we envision managing complex models in general? As you are probably aware large models have an increased risk that a breaking change in a peripheral type will force a new version on the entire model. Since data must be manually migrated today, this creates a maintenance load that we would be keen to address.
Hi could you share an example of a transformation to load a type that has multiple links to another type? All the examples I’ve seen only set startNode and endNode but no place to specify which field. For example:type Composite { frontPart: Part backPart: Part}type Part { ...}
I created a data model that contains an interface (this is to allow polymorphism). When a type references the interface then the the Data Management table shows this error:It seems the UI relies on every reference to contain an externalId field, and that this field is implicitly defined for types but not for interfaces, as the GraphQL query returns with this error: "Validation error of type FieldUndefined: Field 'externalId' in type 'Twin' is undefined @ 'listEquipment/items/twins/items/externalId'"In the above Twin is an interface type, and Equipment contains a field which is a reference to an array of Twin.
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.