There are certain fields in form where instead of a single value, we need an array of values to be stored. This are fields under the same category but having multiple elements, e.g., Tracks, Session Types, Microlocations, Sponsors, Social Links and similar such fields. Now as we know the way of doing this using simple html is provide the <input> tag with property “name” as “<field_name>[]”. So suppose we want to save the names of the mutliple tracks, we will have something like this
But the problem begins when you want to update name of a particular element (in this case Track). How to do it? Should we delete and create entries again? That doesn’t sound too good, does it? So what should we do? Let’s see….
Delete. Save.
So as said above, one of the easiest way of updating is when you get the updated input, you delete all the previous entries and save the new data again to the DB. Well that works perfectly fine with some fields such as Sponsors because no other table have dependency on Sponsors table. But what if another table has a foreign key constraint on the table you are updating.
For example, Sessions depend on the Tracks table because a session belongs to a particular table. So what happens when we delete a track and then save it again to DB to update. Well, the old track with the actual track_id is lost, which means the session is no more linked to any track or may in fact even be deleted all together depending on your constraint. All in all its a complete disaster!!
Thus, as anyone can say, this is not a good practice. So what should we do?
Use ID to Update
Well, this might seem obvious that we need an ID to edit or update the information, but how do we use tor submit the ID so that it can be used to update data in backend.On way of doing it is hidden input field. You can use an input field which won’t be shown to the user, but contains the ID(e.g. Track ID) which is submitted on the form submit. At the backend you can get the object(Track) using this ID(Track ID), update the values such as name, color, etc., and then save back to the DB. This is pretty effective.
Another way of doing is before the form is submitted, you can send the array of IDs as a data appending to the already existing form data using Javascript. This is also a really effective way of doing.
However there is a small security issue in this one. One might modify the value of hidden input field using javascript hacks or inspect elements which would then actually modify a separate Track which they might not have permission to edit. So, how do we take care of this?
For this we not only filter the data from Table based on the Track ID(or any other ID) but also with the event ID. How this makes editing secure and correctly based on permissions is, users can only edit events in which they have write access. So if they send a POST or PUT request with a particular event ID, they must have permission to edit informations of that event. And since we also filter using event ID so the Tracks ( or any such fields like Session Type) that he can edit will belong to this event which he has permission to write. So this way we can handle the security issue in the backend.
One last thing to take care in backend is suppose we remove a Track while updating which was previously there. So we need to delete this track from the DB. So we make a check whether there was so Track ID presently which is no more present in the form data requested and delete all such entries from the DB.