In the last episode, we were talking about the data objects and how they stay the same regardless of any changes. But how does this work in the Platform? Surely, something needs to remain unchanged to keep that "sameness" intact. This something is called the Reference, so let's take a look at what this is and how it works.
Let's implement this Cashiers and Working Shifts functionality and find this out.
First, I'm going to create the Cashiers catalog and add a few attributes here: first name, last name, and the phone number. For the phone number, I'm going to specify the mask - instruction for the Platform on how to format the input string and what can be allowed in this field. Digit 9 here is a placeholder for any digit, so this is our phone number format. This catalog goes to the Lists subsystem.
Now I'm going to add the WorkingShifts document. It has to refer to the Cashiers catalog and have Start and Finish attributes, marking the beginning and the end of the shift. The document goes to the Documents subsystem.
Now I'm running the app, adding Agnes The Cashier and the shift she has worked lately.
I can change any cashier data, but it still will be the same cashier, and the shift will still belong to her. This is because the WorkingShift document stores the never-changing part of this data object - its reference.
If I open the Cashiers standard attributes, I will see it right here. This is what makes an object the object - its unique characteristic that gets assigned when the object is first created, never changes during its lifetime and disappears forever when the object gets deleted.
The Ref attribute is based on a so-called Universally Unique Identifier, and its value looks like this.
It may be hard to believe, but this value is unique across all applications anywhere in the world. So, when we create a data object, we create a genuinely unique entity that can never be confused with any other one.
This is what the WorkingShifts document will store in its Cashier attribute. And this is the only thing it needs to know about the Cashier. All the rest can be retrieved by this reference at any time.
But what happens with this WorkingShift document if we delete the Agnes record from the infobase? Let's see. I'm deleting the item, and here we go: "Object not found" error instead of the Agnes Blue - my favorite cashier.
This is what broken referential integrity looks like. The document still remembers the reference, but now it points nowhere.
So the Referential Integrity is when each and every reference points to an existing object.
But why didn't the Platform prevent this from happening? Well, the Platform does not require that all references point to existing objects all the time. This would be way too strict of a limitation. For example, you, as an application developer, would have a hard time cleaning temporary objects after your tests. Instead, the Platform allows us to decide how strict we want our referential integrity to be.
The most common scenario is when a very limited number of users are allowed to delete objects interactively. Most of the users should use only the deletion mark. So, let's restore the Agnes record and see what this deletion mark is about.
Now, when Agnes is back, I can mark her for deletion. What actually happens here is this standard attribute gets set to True.
The object itself doesn't get deleted, its reference stays the same, so the working shift continues pointing to the same object and feels just great about it.
The marked objects stay in the database until somebody runs this Delete Marked Objects standard command. I'm selecting Full deletion here and clicking Delete. The Platform scanned all marked objects and said it could not delete it because somebody is using the reference. If I click Next, I'll see my Agnes and the Working Shift referencing to her.
If I really mean this, I can open the document and mark it for deletion. Now the Platform will have no issues with my request and both the Cashier and the WorkingShift will be deleted.
One last thing before we move on. How do we allow the interactive deletion for some users and deny it for others? This is what we use Roles for, which is way beyond the scope of this episode, so I'll just show you real quick where it lives.
So, the Roles live here in the Common group. I'm going to add a new role. And now, I can select all Catalogs and here are the rights controlling who can do what deletion-wise.
If I select this check box, all users belonging to this Role will be able to delete any catalog item interactively. If I clear it, they won't even see this menu item on their screens. This is how it works in a nutshell. And there will be the entire module in the Senior Developer level devoted to the access rights specifically. So, as always: stay tuned!