How do you handle automatically created fields like database primary key and created timestamp?

[simkimsia]

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?

[hjwp]

on primary keys, you have two choices. one is to use your domain identifier (a batch_reference in 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 around batch_reference later. 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 FakeRepository that sets a timestamp based on time.time() for tests, when you call repo.add(), and the RealRepository delegates the timestamp-setting to the ORM/database. does that helpP