Repository navigation
How do you handle automatically created fields like database primary key and created timestamp? #299
Description
if I am not mistaken the repository for the batch is that it will take in the batch entity for the add function
Let's say I want an entity to also store the database primary key after it's been created and other fields that are automatically created such as timestamp for created
Does this mean that the add function of the repository need to take in the __init__ of the Batch instead rather than the Batch entity itself?
Activity
hjwp commentedon May 1, 2020
on primary keys, you have two choices. one is to use your domain identifier (a
batch_referencein our case) as the primary key. the alternative is to use a surrogate primary key (which the domain model is unaware of) and just leave a unique constraint + index on the column that has the domain identifier in. the tradeoff is that the latter buys you flexibility of being able to change your business rules aroundbatch_referencelater. but it's more complex.re: timestamps i'm less sure -- I'm guessing you want to say that the database is in charge of setting timestamps, because it's a single source of truth, rather than various application servers that might be on different machines and suffer from clock skew? but you still want the timestamp to be a domain concept?
if so I can imagine having a
FakeRepositorythat sets a timestamp based ontime.time()for tests, when you callrepo.add(), and theRealRepositorydelegates the timestamp-setting to the ORM/database. does that helpP