Updating attributes of a Rhino published commit with GraphQL

[jonathon]

@lukxfnz

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?

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)

@lukxfnz

Would be neat if…

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.