Before Save and Unique Indexes

No-Code Platform
1

Hi there

With the Before Save event on an application - does a unique index constraint on a table get considered before the Before Save event is run on an application? In other words, if there is validations running in the Before Save, will the referential constraint error be thrown first before the before save validations run / throw errors?

Thank you.

2

The index will be applied after the Before Save event. It occurs when the record truly goes to the database, which is during the “save” step.

3 Likes
3

@brendan.b In my testing, it was throwing the unique constraint error before hitting the before save error. I have subsequently removed the unique index and letting the before save and triggers run validations. I expected the before save to take preference, but was not doing that in my testing.

Side note: I was doing a before save event on an application with a subtable and only the subtable was editable. The subtable had the unique index. Could this result in the unique constraint error being thrown before the before save?

4

Very interesting. I must be mistaken. Let me confer with some folks and we’ll get back to you.

5

@claire.minnaar I think there are two potential causes here. For a little background, like Brendan said, duplicate key indexes are validated at the database level. So whenever a violating record is persisted to the db, the error will be thrown. This typically doesnt happen until the nate container commits because we add the nate container’s id to the unique index, so if a live record exists and you insert a duplicate in your container, we wont detect the duplicate til we transition the record to live during the transaction commit.

For your case, my guess is a duplicate record is being inserted during the before save logic which throws the error because both records (the one being saved and the one inserted) are in the same container. Could that be the case?

2 Likes
6

@joe.graff

Here are the steps done to confirm exact scenario/steps involved:

  • Launch a mini app which only displays the subtable on a given record (Subtable has a unique constraint on it)
  • Add a new line in the subtable with a value which should violate the unique constraint
  • Save and Exit/Stay
  • Foreign Key error is thrown instead of the Before Save validation which would show a more user friendly message

So assume it’s the scenario you explained above? Would this be correct or a bug?

7

There’s probably a few unanswered questions that we can ask to approach why the duplicate key error is occurring when it is. @claire.minnaar can you respond to the below?

  • What is the error message?
  • Does the error reference the subtable or the main table?
  • Does the mini-app extend the transaction boundary of something else or is it its own process?
  • Is the before-save logic configured on the mini app or on a different app?
  • What does the before save logic do? Is it essentially “loop subtable → if multiple duplicates detected → error” or something else?
  • If you debug the before save logic, does the session start or does the error occur before the session begins?
  • If you add a record to the subtable that does not violate the unique key of the subtable, does everything work correctly?
8

@ross - Please see answers to your questions below.

  1. Error reads: Error - Failed to create the record because a duplicate record already exists. See message details to know what combinations of field(s) make each record unique.
  2. References the subtable
  3. Mini app is launched with Application Link (Save Not Required), so runs outside of the transaction boundary. It’s kicked off from an application which doesn’t allow any fields to be edited, so a save isn’t required.
  4. Before save is on the mini app’s Before Save event.
  5. Loops and checks if there is a duplicate entry and will throw an error.
  6. Error is thrown before the before save logic kicks off.
  7. Yes, 100%

Thank you.

1 Like
9

Thank you Claire for the info! This statement leads me to believe that there might be a bug somewhere and the system is validating the record set before the Before Save logic applies at all. @joe.graff do you concur with that or need some additional context to definitively say “bug”?