Timestamp fields such as createdAt or lastUpdatedAt in your entities

[Joo Lee]

Hello guys,

I don't know if this is a habit I picked up from working in OO + relational database projects, but in my Lagom projects almost all the entities I created have a field called "lastUpdatedAt" or "createdAt" of type Instant which simply indicates the last time the entity was updated or to record the time when the entity was created.

But I don't really know if this would be any useful at all. And in fact, having those Instant fields are making my unit testing bit difficult. 

I initially thought that for example, some business user might wants to know when was the last time this Portfolio aggregate root that he is looking at was updated. But why would he care about it? 

So I thought about it more deeply about why I used to have those fields in my case classes in my previous non-Lagom-non-CQRS projects. And I think there were three main reasons:

1) For Auditing 

We want to know who screw up the business data and punish them

2) For Production Support (Re-run-ability)

For example, when some batch process that updates the tables was stopped due to some errors in the middle and as a result some data got corrupted,  we may decide to re-run the batch processes to fix the problem. And here the timestamp field such as lastUpdatedAt plays a crucial role to distinguish which ones to include in the new batch and which ones to exclude. 

3) To check the freshness of the data

Business users such as traders want to know that how "new" the data is. For example, if the screen displays the stock prices, users want to know when was the last 

time they were updated.

And I think in CQRS you don't have to have timestamp fields in your entities for the reasons 1) and 2) from the above. Because the event stores can serve the purpose of auditing. And for 2), your PersistentEntities should be designed in a way that it can handle the re-run-ability by itself. For example if the batch process stopped in the middle and only 20 out of 100 Entities have been updated by the commands, one should be able to fix the problem by re-running the entire process again on all 100 entities because those 20 Entities that have already been updated should be able to handle the duplicated commands either by applying Idempotency pattern implemented in it, or simply by ignoring the duplicate command by being in a different state.

But for the case 3), I think it is the business use case, which then it make sense to have this type of field included in the Entities definition.

 

What do you guys think?

Thanks,

Joo

[Tim Moore]

Totally agree, Joo.

In addition, using timestamps for system purposes (particularly for ordering) can have some unintended consequences in distributed systems, where clock drift can be a real factor.

See "There is No Now" and "Time is an Illusion" for some fascinating takes on the subject.

This is largely mitigated in Lagom by its use of a single writer for each entity instance, so as long as you're not comparing timestamps between different entity instances, it's less of an issue in a Lagom-based system.

One thing I'd say is that there still may be a use case for storing timestamps for auditing purposes, if you have a business domain requirement for auditing: whether journal entries are timestamped is implementation-dependent. I think Cassandra persistent entities do store timestamps in the journal, but JDBC ones do not. The akka-persistence-jdbc implementation uses sequence numbers instead.

Cheers,

Tim

--
You received this message because you are subscribed to the Google Groups "Lagom Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lagom-framework+unsubscribe@googlegroups.com.
To post to this group, send email to lagom-framework@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lagom-framework/229754c0-6e33-4875-84fd-66d66e11a412%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Tim Moore

Senior Engineer, Lagom, Lightbend, Inc.

tim....@lightbend.com
+61 420 981 589
Skype: timothy.m.moore