You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the only submittable artifacts alchemiscale supports from users are AlchemicalNetworks. This has worked well, but some users would like to be able to submit custom metadata associated with their AlchemicalNetworks that can be used for processing results downstream without needing an external system to retain this information.
To support this, we could add a metadata kwarg to AlchemiscaleClient.create_network that takes in a string as input. This string could contain any information a user believes they need associated with their submitted AlchemicalNetwork on initial submission, with perhaps server-side size/length limits imposed to keep these from being arbitrarily large. Restricting the data type to strings puts the burden on the user to serialize this data in a form they can deserialize before it hits the client, and avoids forcing them to use a particular data model, e.g. pydantic.
This string could be stored in either the state store or the object store. The state store would give faster retrieval, but the object store is more suitable for potentially large objects.
There may be other possible solutions with benefits/drawbacks. We will collect these here before proceeding to an implementation.
The text was updated successfully, but these errors were encountered:
Currently, the only submittable artifacts
alchemiscale
supports from users areAlchemicalNetwork
s. This has worked well, but some users would like to be able to submit custom metadata associated with theirAlchemicalNetwork
s that can be used for processing results downstream without needing an external system to retain this information.To support this, we could add a
metadata
kwarg toAlchemiscaleClient.create_network
that takes in a string as input. This string could contain any information a user believes they need associated with their submittedAlchemicalNetwork
on initial submission, with perhaps server-side size/length limits imposed to keep these from being arbitrarily large. Restricting the data type to strings puts the burden on the user to serialize this data in a form they can deserialize before it hits the client, and avoids forcing them to use a particular data model, e.g.pydantic
.This string could be stored in either the state store or the object store. The state store would give faster retrieval, but the object store is more suitable for potentially large objects.
There may be other possible solutions with benefits/drawbacks. We will collect these here before proceeding to an implementation.
The text was updated successfully, but these errors were encountered: