Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UpdateOnly - Enable update individual properties only on push #185

Open
rwemay opened this issue Feb 3, 2020 · 3 comments
Open

UpdateOnly - Enable update individual properties only on push #185

rwemay opened this issue Feb 3, 2020 · 3 comments
Assignees
Labels
type:question Ask for further details or start conversation

Comments

@rwemay
Copy link
Member

rwemay commented Feb 3, 2020

Having recently been enabling the UpdateOnly for Robot_Toolkit (is working really well!) I'm thinking it would be good to extend/expose a bit more structured interaction to the human interface.

A specific workflow to enable could be: push property changes of objects to specific objects/a selection only, without needing to pull/construct the whole object. At the moment, the typical update only workflow means pushing an object with all properties required to be set, otherwise null or empty properties will reset the properties in the external software. Moreover, there are some object properties that the current toolkit/behavior preclude, e.g. changing of object numbering in Robot/structural adapters, as the comparers are hard coded.

As a suggestion, the specific workflow could be enabled through the current Push component, and by pushing 'bespoke' or specific classes into 'objects' input that contain:

  • ObjectType - the types of object whose property is required to be updated;
  • Comparer (or ObjectComparer) - the property of the object to compare. This needs a bit of work, as I think we should expose 'Comparerers' more generally in the human interface, so that people can compare things in any workflow;
  • PropertyName - the name of the property to be updated;
  • PropertyValue - the value to update the property to.

Specific workflow: modify the node numbers of a Robot analysis model by comparing the nodal coordinates and updating the numbers where they match within a human-specified tolerance.

Thoughts on a postcard @al-fisher , @alelom , @IsakNaslundBh

@rwemay rwemay added the type:question Ask for further details or start conversation label Feb 3, 2020
@IsakNaslundBh
Copy link
Contributor

We actually used to have a method not to dissimilar to this on the base Adapter interface (UpdateProperty) but it was never really properly implemented in any toolkit and was decided to get removed for now a few months ago with focus on getting the push fully functioning with proper support for the UpdateOnly workflow. Link to method from 2.0 release branch here:

public virtual int UpdateProperty(FilterQuery filter, string property, object newValue, Dictionary<string, object> config = null)
{
return PullUpdatePush(filter, property, newValue);
}

Might be a candidate to bring back again at some point (maybe tweaked a bit according to what your findings adding the Update methods for Robot @rwemay ). If added back in, it would be nice to get it functioning through the CRUD methods already in place though I would say (if possible) to avoid having two completely different sets of methods to maintain + avoid confusion between Update and UpdateProperty!

@IsakNaslundBh
Copy link
Contributor

Also, general exposure of comparers to let users choose I think would be a quite cool feature. Having default ones stored on the adapter itself, controlling the standard workflow (merging nodes by coordinates etc) but being able to, if you wanted to, instead merge nodes by name, bars by section or whatever weird and wonderful thing you might want to be able to do:+1:

@rwemay
Copy link
Member Author

rwemay commented Feb 3, 2020

Right - perfect, UpdateProperty was what I had in mind, but would be great to weave into current adapter/interface, if it's not pushing too much in/complicating it for humans too much. Agree on comparer exposure, could be really good. Also a good way to expose to people how complex these operations can actually be - not every workflow works with strick/hard coded node numbering!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:question Ask for further details or start conversation
Projects
None yet
Development

No branches or pull requests

3 participants