Repository navigation
How do you handle automatically created fields like database primary key and created timestamp? #299
Description
Activity
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 helpPReacted by Greg Brown
if I am not mistaken the repository for the batch is that it will take in the batch entity for the
addfunctionLet'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
createdDoes this mean that the
addfunction of the repository need to take in the__init__of the Batch instead rather than theBatchentity itself?