Hey @AlanRynne are you able to provide any more info on how to achieve the above? I’m wanting to update user-attributes on some breps from a commit, but via Graphql. Getting a bit stuck on how I would achieve this with a graphql mutation?
Use case is:
User A creates Rhino geometry with user-attributes and sends to Speckle
user-attributes pulled into web dashboard via graphql query
User B manipulates user-attributes via dashboard, pushes updated user-attributes back to Speckle
User A receives latest commit and can see the update user-attributes
user-attributes might be some key-values like approved: false or ordered: true.
It’s not possible to modify the data inside a commit, the correct process would be to instead create a new commit with the updated geometry/metadata and send that with our REST/GQL API.
This will also ensure the Speckle id of your objects is updated correctly since it’s a hash of the object itself.
Yeah @teocomi - any help on how to structure that Graphql mutation/REST to send a new commit with updated info?
I was hoping to keep the data closely tied to the geometry but for what I’m trying to do it seems it might be worth sending it to a different branch i.e. data branch? Otherwise it seems messy to do a partial retrieval via graphql and then have to package it all back up for a new commit?
Does that make sense or am I looking at this wrong?
There often multiple ways to achieve data roundtripping and these partial updates.
The separate branch approach might be possible, but you then need control over what is stored in which branch and how things are kept in sync. If there are clear divisions/boundaries, then Branches could be the perfect solution.
Where the set of elements being amended is more ad-hoc, it becomes a harder proposition. You may find that what you see as potentially messy about committing some updated and some not-updated elements is the most straightforward approach.
I think I was initially looking at the graphql query as retrieving only the data I’m interested in, something like column.colour: blue - but what I think I’m understanding is that if I want to update that attribute I would have to actually download the entire commit, probably via REST rather than graphql, access and update the column.colour attribute, and then send the updated commit back via REST? Anything unchanged won’t get updated, but I still need the entire commit structure?
Splitting the data off seems practical for simple key-value updates (the geometry takes a while to upload from Rhino, so I don’t think it’s practical to download the entire commit to a dashboard just for updating attributes?). I imagine on the Rhino end I could associate the user-attributes via an id and then write a script that updates the user-attributes from the data-branch?
Would be neat if I could send a graphql mutation with only the updated attribute/id with a flag that indicate I wanted to create a new commit derived from the previous commit with only the updated attribute(s) being changed? Would remove the need for having to have all the commit data to be able to “update” bits and pieces as needed?
That’s the most straightforward strategy. In essence that is what all the connectors do (in combination with caches and transports)
In a basic description, the Speckle server holds all versions of whatever objects are sent to it over time. It is the latest commit or collection of commits that lists the objects that represent the “current” version of project totality.
So, while you could select a subset of current objects, change those and send only them as a REST call, Retrieval of the new totality would be complicated. Not impossible, but only possible from your code. Any connector only uses commits for that purpose. That said, if you receive the truncated commit in Rhino it would do it’s best to handle the changes. The web viewer notsomuch.
Branches are a helpful device to organise separate “latest” commits but only if they represent consistent boundaries to your changes and collectively represent the total (in your case unlikely)
This is a legitimate feature request for a Mutation (excuse pseudoQL)
WITH commitId xxx REPLACE objects [yyy = {zzz}, …]
Where yyy is the previous Id and {zzz} is the new object with changed user-attributes . The server would respond to this by effectively creating a new commit of the old commit objects, minus the changed ones plus their replacements - and returns the new commitId
i.e. what we’ve both talked about in the previous posts but all it is doing is moving the the curation task from client-side to asking server to assemble commits on your behalf server-side.
I say legit because it is in the minimal payload ethos of GraphQL , not because it is supported
This theoretical Mutation is still posting the entire new object not just the amended attributes. Its sibling mutations would be WITH commitId ADD and WITH commitId DELETE.
Apologies this is a looong response, but if you think it summarises something helpful, I’ll discuss it with the team.
—-
To the data branch idea, if you are scripting in Rhino anyway the world’s your but I really don’t know how you are using these attributes to think of an ideal approach.
Your replies are appreciated since I’m new to graphql . I like that a change equals a new commit across Speckle, but if a mutation could handle the data-structuring server side so your above examples worked would be ideal. (Something like a feature flag in the mutation?)
I’m trying to work across a design and fabrication team, so having the geometry and data coupled is fantastic, but my fabrication team isn’t using Rhino/Revit/SketchUp, just a CRUD dashboard, so having them easily able to update attributes is the dream.
If it’s viable to set-up mutations to handle the new commit structure then maybe adding it to the roadmap would be nice (personally, I think it would simplify a lot of use-cases for custom dashboards and app development etc), but I’m unsure what the appetite for such functionality is amongst the community. I haven’t come across a lot of other people working/talking about graphql on here…
Thanks Jonathon ~ I’ll investigate creating new commits
Speckle server holds all versions of whatever objects are sent to it over time. It is the latest commit or collection of commits that lists the objects that represent the “current” version of project totality.
, not because it is supported 
but I really don’t know how you are using these attributes to think of an ideal approach.