Feature Request: UUID as a Field Data Type

Tap Forms – Organizer Database App for Mac, iPhone, and iPad › Forums › Using Tap Forms › Feature Request: UUID as a Field Data Type

Tagged: 

Viewing 3 reply threads
  • Author
    Posts
  • February 26, 2018 at 10:33 PM #27499

    prov0356
    Participant

    Hello Brendan.

    Please consider making a new field data type of UUID in addition to its current use as a formula for Calculation field types. I use UUIDs extensively as primary keys and for the Join fields (foreign keys) on many-to-many relationships. Because I use UUIDs as primary keys, once I create a new record, and the UUID is calculated, I never want the value to change. Hence, I select the option “Calculate one time only” in the Formula Editor dialog. Having my key fields be Calculation fields is working well, but there are some nuances. For example, when using the Duplicate Record feature, I want the new (duplicated) record to have a new UUID. Since the field is not open for input (due to it being a Calculated field) and since it does not get recalculated (because I set it that way), I really cannot use the Duplicate Record feature (which would be very helpful). I think making UUID a field data type would solve these issues since you could handle the key-related UUID behaviors differently from the current formula-/calculation-related UUID behaviors. (Another bonus would be that you could use the UUID fields as the default selections for the Join fields in the dropdown lists for the Join link-to-form type.)

    Alternatively, extending the Text field data type by providing a UUID attribute option (similar to the Required Field attribute option) might work, so long as the UUID value is system-generated as a default value. However, once the UUID value is provided, there could still be some confusion about what the expected behavior should be when a record is duplicated. On the one hand, it could be argued that since the field is first and foremost a Text field, its value should be duplicated just like every other field on the form. On the other hand, it could be argued that even though the field is a Text field, since it is marked as a UUID (or Key field, etc.), its value should not be duplicated, but rather a new UUID value would be generated for the duplicated record.

    I would be interested in your thoughts on this and the thoughts of other Forum members.

    Thanks.

    February 27, 2018 at 12:19 AM #27501

    Brendan
    Keymaster

    It’s definitely a more advanced feature for power users. Try explaining to a grandmother managing their recipes what this new UUID field type is for? :)

    But it’s certainly doable.

    I’ll think about it.

    March 2, 2018 at 2:31 PM #27568

    prov0356
    Participant

    Hello Brendan, I’m going to withdraw my request for this feature. I have figured out how to achieve what I needed for many-to-many (M:M) relationships without using UUIDs at all. Basically, if I have two forms, A and B, with a M:M relationship between them, I will create a form, AB, and then create a 1:M link from A to AB, and likewise, a 1:M link from B to AB. This seems to work well, plus I get the added benefits of (1) I can have AB-specific fields, and (2) I can use the record lookup feature (the “check mark” feature) that is available for link relationships, but not join relationships. I should have thought of this earlier: treating a M:M relationship (that has fields of its own) as two 1:M relationships.

    March 2, 2018 at 5:42 PM #27573

    Brendan
    Keymaster

    Ah ok, great. Yup, that’s exactly how M:M joins are done at the database level, with an intermediate table.

  • Author
    Posts
Viewing 3 reply threads

You must be logged in to reply to this topic.