Better Object Handling for "Subtypes"

Product Suggestions
1

Problem:

While working with connector outputs, Tulip developers frequently have to rebuild large pieces of applications when parts of the output model change. In complex apps this can make it so that you need to update dozens of triggers in order to add one column to a model. In addition to being time consuming, this can be very error prone because of the complexity required in these use cases as well as the general user experience with objects not being great.

For an example, if my app currently uses a list of Work Orders (Model v1) and I need to update my ERP integration to use Model V2 with additional keys, this will require completely blowing up my apps which use this model.

Potential Solution:

If Tulip object logic allowed for addition of keys so that Work Order Model v1 could be stored into an object of Work Order Model v2, it would make it significantly easier to cutover these changes.

// Work Order Model v1
{
   id,
   item_id,
   quantity
}

// Work Order Model v2
{
   id,
   item_id,
   quantity,
   upc_code
}
Object list editing
2

Hi @danielpomeranz , thank you for posting.

Flexible object handling to reduce rework on model changes is definitely a known pain point. As you mention, it would require better Object support, possibly a rework of how we manage objects on the backend. This is a bigger swing, so we started with Connector Versioning, Functions, and Where Used improvements first - which will take us through the first part of the year.

We’re currently figuring out which “big swing” problem areas to take on next. Thank you for upvoting this one, and we’ll continue keeping an eye on votes here.