Impact 2024: The Industrial Data and AI Conference for and by Users | Nominate Speakers Now for a Ch...
Correct. As of today, we don’t support required relation fields like that.
Yep, we don’t support changing a property to be required (or from required to not required). It is a known limitation and on our list of improvements, but we don’t have a timeline for it unfortunately.
We are happy to share that transformations now support edges! It should appear naturally in the list where you choose what to ingest, and you are guided to find startNode and endNode which are the two required properties on the edge (in addition to the edge type).
We had a brief discussion about files and documents in our previous meeting. I have not spent time on how to do model documents according to CFIHOS properly, but FDM will support references to CDF File objects. This means it is definitely doable, and we just need to figure out the best way to do it.
There is no workaround. The reason is the following:If node X is in space A with a reference to node Y in space B.If I delete my node Y, but don’t have access to delete your node X, what should happen? I definitely see the use case, but we will not have a solution for this on the short term.
Hi, for relations to other types, we don’t support the requiredness. You will not be able to have this strict requirement due to the coupling of nodes this would require. For strings, what you can do istype Department { name: String!, someStrings: [String!]!}which achieves what you want. The someStrings property is then never null, but can be an empty list. String lists are stored on the same node instance.
Hi,We introduced a regression that should have been fixed now. Sorry for the inconvenience!
I assume here you mean the REST API? I think it is possible using the query end point, but we have not documented this yet. It will come over the next weeks, so use GraphQL in the meantime.
The official API docs will be released a few weeks after according to planned (but not broadly announced). The PR link previously shared is still the source of truth, and no breaking changes are planned.
Duplicate node externalIds only occurs if the same transformation tries to ingest the same node twice in the same API request. Can you please check your data source to ensure that you don’t use the same externalId twice? Let us know how it goes:)
You can ingest with the same external id, so this should not be caused by that. This is very likely to be duplicate externalIds in the transformation, which is easy to do by mistake. Can you run the same transformation to RAW and verify that all the data is there without any duplications?If you are certain there are no duplicates, it would be great to get more information about which transformation it is, so we can investigate with the team.
Hi, this is a great feature request and is on the roadmap. Will reply here with updates.
Already have an account? Login
Enter your 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.