2x ParameterUpdater

Hello! :slight_smile:

I’m getting closer to actually SEND parameter data to the server. :smiley:

Now, I came upon two “ParameterUpdaters”:

1. Objects.BuiltElements.Revit.ParameterUpdater

It’s the one from Grasshopper and also e.g. the Parameter Panther and uses the @Data object in the database.


2. Objects.Organization.DataTable

It’s the one from the newly presented “ParameterUpdater” feature (Excel/Revit) and uses the data, rowMetadata and columnMetadata properties in the database.


So my questions would be:

  • Besides their similar name, do those have anything to do with each other?

  • It seems that the second one (DataTable) indeed only works with Revit schedules? Importing the (changed) data back into Revit doesn’t seem to work, if the schedule doesn’t exists (anymore). It’s data will not be applied to the elements directly, right?

  • Out of curiousity: What if the Revit schedule changed since the last export (columns, elements, sorting, filter, grouping) … would the import still work?

  • So, when wanting to update parameters in my Revit model (with no schedules) via an external web app, version 1 would be (the only?) way to go?

Thanks in advance! :slight_smile: :pray:


Naming things IS hard. There is no functional connection between the GH ParamterUpdatar and the ParameterUpdater feature of Excel<>RevitSchedules recently announced.

There clearly is a functionality similarity in that they both update parameters but the lack of distinction is our fault.


Good questions!

  • as @jonathon said there is no correlation between the two
  • correct, the DataTable parameter updater is set to work on schedules that exist. For now only in Revit, in the future in other software too
  • I’ll pass this one over to @connor
  • yes, Objects.BuiltElements.Revit.ParameterUpdater would be the way to go. This is a quite old feature that was developed specifically with the GH>Revit flow and so we’re happy to get feedback on how it could be improved. Depending on how your app is structured, another approach (more complicated) is to send back the original SpeckleRevit elements with updated parameters; if you do this you should also make sure to update the Speckle IDs/hashes of such objects.