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 a reference. 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 cashier's 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 digits. This is our phone number format. This catalog goes to the list subsystem. I'm going to add the working shift document. It has to refer to the cashier's catalog and have start and finish attributes marking the beginning and the end of the shift. This document goes to the document subsystem. Now I'm running the heading, 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 working shift document stores the never-changing part of this data object, its reference. If I open the cashier's 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 so-called universal unique identifier. Its value looks like this. It may be hard to believe, but this value is unique across all applications anywhere in the world. When we create a data object, we create a genuinely unique entity that can never be confused with any other one. This is what working shifts document will store in its cashier attribute. This is the only thing it needs to know about the cashier. All the rest can be retrieved by this reference at anytime. But what happens with this working shift document? We delete the admins record from the info base. Let's see. I'm deleting the item. Here we go. Object Not Found error. Instead of the, Agnes Blue, my favorite cashier. This is what broken referential integrity looks like. The documents still remembers the reference, but now it points nowhere. 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 pointing to existing objects all the time. These 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 object's interactively. Most of the users should use only the deletion mark. Let's restore the admins record and see what this deletion mark is about. When Agnes is back, I can mark her for deletion. What actually happens here is, the standard attribute gets set to true. The object itself doesn't get deleted, its reference stays the same. 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 working shift 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. I'll just show you real quick where it lives. The roles live here in the common group. I'm going to add a new role. Now I can select all catalogs and here are the rights controlling who can do what, deletion wise. If I select this checkbox, all users belonging to this role will be able to delete 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. There will be the entire module in the senior developer level devoted to the accessorized specifically. As always, stay tuned.
