Consider adding new fields to Thing

[dborovcanin]

ENHANCEMENT

1. Describe the enhancement you are requesting. From real-world experience with the Mainflux platform, we noticed some common requirements such as last seen and device status (active, online, offline, error, blocked, corrupted...) as well as a serial number that represents an external unique identifier assigned to the device the Thing represents.

One of the most commonly requested features is "last seen" which manifests itself in different forms. Imagine the following case: I want to get serial numbers of devices that did not send any messages in 3 days. What we need to do to enable it now:

1. Add a metadata field that represents a serial number. While this looks (and is) perfectly fine, we waive the convenience of DB-level constraints such as required or unique, and we make searching against it more complex than it is supposed to be.
2. We need to store messages in order to fetch the most recent ones. While inconvenient, this is usually the case (the user will use Writers to store messages) so I think this step is OK.
3. Fetch all the latest messages grouped by the unique publisher and find the difference between that set and set of all the existing Things. If we could guarantee that each Thing has sent at least a single message, we could skip this step and only use stored messages to find which publishers are not sending new messages. Even in that case, we'd have only Thing IDs, not serial numbers.

There are multiple approaches to this problem:

Add a new "last seen" field

Add a new field and update it whenever Thing sends a message. Pros are that we don't even have to store messages. Cons are that this operation can be quite frequent and it can get resource-heavy for cases with Many Things that send data frequently.

Add a new "status" field

Basically, the same approach, but more generic. The status update can be done by a rules engine which can process the message and decide to update the status depending on the content. It requires even more processing but provides more versatile options.

Process logs

We can solve the problem on the deployment level by adding a log processor where we can extract useful information from adapter logs. Pros are that we're already using machine-processable logs. Cons is that we are limited by the amount of data we have in logs, and sometimes it is not sufficient. We can say when was the last message sent by a specific device, for example, but processing logs is not sufficient in the example provided above.

We can always use metadata to put such information in it. The benefit of that approach is that it's simple (and we tested it), but the drawbacks are that we make it more complex to process and we give up some benefits of SQL constraints. So, basically, the questions boil down to this: Are these requirements sane enough to consider updating your model or we should stick up with metadata? How do we handle described scenarios on the architecture level (process logs, use rules engine, hardcode updates in the code)?

2. Indicate the importance of this enhancement to you (must-have, should-have, nice-to-have). This is a nice-to-have enhancement.