Impact 2024: The Industrial Data and AI Conference for and by Users | Nominate Speakers Now for a Ch...
Hi, this is a great feature request and is on the roadmap. Will reply here with updates.
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.
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:)
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.
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.
Hi,We introduced a regression that should have been fixed now. Sorry for the inconvenience!
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.
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.
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.
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).
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.
Correct. As of today, we don’t support required relation fields like that.
Yeah, this is following the GraphQL spec. You can actually use interface everywhere and that should work fine!
The bug has been fixed and rolled out to all production clusters now.
Hi,Seems like we introduced a regression here. Will work on a fix and update this post when it’s done.
Hey,Yep, that is a good idea. We do have an implementation of CFIHOS as a part of validation of flexible data modeling.Note that CFIHOS is huge and somewhat complicated, and is likely to be a good target state. However, I would recommend getting there in steps. Increase the cardinality of the class library step by step.
Hi, thanks for asking. This is being added these days and should be available in the UI within a week or two. In the meantime, the API can be used to add edges.
Hi,This one is interesting! I’ll do some digging and get back to you on it.
You will be able to list native time series directly as if it was your own type, so unless you want to add extra metadata, you shouldn’t have to do that.
Not sure I follow the question here, but as long as you put in the externalId of a time series, it should be available for querying in your data model.
I see! So it is possible to use TimeSeries as a type in FDM, but we are finalizing the details, so it is up for change still. However, if you today use TimeSeries as a type, for instancetype Device { name: String sensor: TimeSeries}you can ingest data where you would use the externalId for the time series as a string field in your SQL transformation. Then you can query it and get the latest data point with{ getDeviceById(instance: {externalId:"abc", spaceExternalId: "abc"}) { items { name sensor { dataPoints(start: ...) { timestamp value } } } }}We haven’t exposed lastDataPoint, but that will come in H1 2023. With the new APIs, the story might be slightly different, but will keep this thread up to date on the topic.
Hi,What are you getting from a query, and which query are you performing?Note that you should probably not FDM as a time series database, but rather use the time series database we do provide.
Hi,Thanks for reaching out. Enum support is on the roadmap, with support from the underlying implementation. Will keep this thread updated on the topic.
You would use the same data model for all of your wells. FDM tells you the structure of the data, and if all of your wells logically fits into that structure you are good to go!
Hi, thanks for using CDF! What do you mean with several models with the same schema? What is the difference between the models in this case? How do you want to use the different models?
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.