Workshop - in-progress editing of object types - best practice question

Ask the Community
, ,
1

A question of best practice for Palantir Foundry Ontology: So if you’re working on editing a singular item, say Customer, then you can do it all in UI: a field for name, some fields for contact info, etc, submit. Those do not need to be stored as we’re editing and only get created in an object on submit.

This is a question of in-progress objects, and I can’t find a similarly good solution for object types with parent-child relationships. They seem to want to be stored in a temporary state, which induces a tradeoff:

Take Order and Order Item. We need to group all Order items under a given Order. So a primary key / unique id is needed. We need to make sure that order is available and would like to reserve it so no one else can use it (especially if using sequential keys). It seems like we should create an Order object and associate Order Items with it on submission.

And we want to display Order Items in a table and provide easy ways to add / remove them. Palantir offers this functionality, but only do so on objects that have been added. So we’d like to make use of that. It seems like we should create the Order Items and use the ontology functionality to enable the UI functionality.

But now we have a small but real added complexity that we pass downstream. There must be a way to distinguish between objects in progress and completed ones. There are basically 2 ways and I’m not completely happy with either:

  1. Create a status column. Setting aside that status could mean many things (I last used “Is Active” ), now we must have that property on anything we want to submit. And downstream has to remember to respect that, which could easily be overlooked.

  2. Create a draft version of the object type. This is cleaner and does not impose the burden of checking for a column, but pollutes the ontology with draft duplicates. There’s a notion of using interfaces which could standardize fields between draft and actual (they both must have the interfaces columns). This has upfront complexity.

I have spent much longer than I would like or like to admit thinking about the pros and cons, and I come away unsatisfied. Is that just the nature of the beast or am I missing something?

1 Like
2

Hi @David_E , I think the solution is the first option. But you can directly include the is_Active column in the backing dataset and set it to a default value. When you do updates or modifications for each transaction on submit (Can be done using TS backed functions), then you will be able to set the is_Active property to a specific state that you want. So, there is no scenario where this will be overlooked as this property is directly included in the Order Item. And as we assume each order has n OrderItem. So, this is the best and straight forward solution. But Im curious to learn if there is a better approach as well.

Thanks!

3

Sorry for the long read, I am still working to untangle the options. TLDR: There are tradeoffs for each of the options to handle batched submission (ie items in an order)

Aside from the ones mentioned above there are a few more that don’t need to write to the ontology directly:

  • Structs/variables returned from functions, set to not update unless explicitly called. Interface options for these seems much reduced from ontology objects.

  • Scenarios have the potential to be great for this problem - it’s a branch that can be applied to the actual ontology, but I ran into 2 bugs, the most prominent of which is that the “On Successful Apply Action” to execute an action after applying a scenario seems to try to get the data upfront, but also get defaults from the ontology, where my changes haven’t been applied yet.

  • Lastly there are ways to use an action table to bypass this entirely. But when you do this you must have individual actions for each of the child items and there can’t be one for the entire batch (or parent). Additionally, you need to pass the parent and some identifying feature for the child (like orderId and itemId) and there are some situations you don’t want the user to be able to edit them.