Improve table field UID handling?

Product Suggestions
, ,
1

Hello,

Currently, table UIDs and table field UIDs seem to work like this:

  • A table UID is simply a sequence of 17 random alphanumeric characters, e.g. M2Py62CePbiiYVizy
  • A field UID is different. It seems to contain 5 random lowercase letters followed by the very first name given to the field in snake case, e.g. kyntc_my_field

I can understand the desire to avoid working with a bunch of random strings when referring to fields in the Tulip API. However I’ve had several confusing cases where a field was renamed because its use evolved in the apps, whereas the field’s UID still contained an inaccurate/outdated name.

Most of the time, users don’t want to create a new field and change it everywhere in their apps just to have an accurate UID… which I totally get. And it might be technically annoying or bring confusion to make a field UID mutable (one could argue it wouldn’t be “temporally unique” anymore). But still, the field UID can be:

  • overly general (kyntc_number),
  • overly accurate but outdated (kyntc_first_name that would actually contain a full name. Or worse, things regarding product quantities, money or sensor measurements),
  • or even completely meaningless since some users are unaware of field UIDs (kyntc_aaaasdf).

So, I was wondering: what is better when working with field UIDs in the Tulip API?

  • A (current situation): work with more meaningful field UIDs that are sometimes accurate, and sometimes aren’t? E.g. kyntc_name which might be a username, a first name, a last name…?
  • B: work only with random strings (e.g. kyntc)?
  • C: work with something halfway by mentioning the field type, e.g. text_kyntc?
  • D: allow the user to change the field’s ID but warn him that this is potentially a breaking change for any Tulip API client (and maybe Tulip apps?).

Similar remarks could apply to tables in general. What do you think about this? Should things remain as they are? Should things change?

2

I have been there myself and it absolutely drove me crazy.

If you ask me, I would like to see either of the two

  • completely remove the original name from the UID: that way it is clear that it is just a field and you have to figure out what that field is - just like with the tables

  • or better but possibly very difficult to implement: allow developers to modify the field name

With the second I am afraid there can be to many places where things would need to be updated. So maybe that is the reason why it is not possible in the first place and a nightmare to develop.

3

btw… I even went as far as creating the fields via the API to bypass Tulips gibberish. But that only works if you have a fixed structure that you want to implement and a bit time consuming. And later should things still need to change you are at the same problem all over again.