Closed carltonwhitehead closed 7 years ago
Not going to implement a paid
field. Doesn't seem like it would satisfy any real-world use case. Also, I don't want to build my own accounting or payment transaction handling at this point in time.
Not going to implement a participating
field. Also doesn't seem like it satisfies any real-world use case. Perhaps at some point it could drive the default competitive
property of a Run
. Seems premature still at this point in time.
Currently leaning towards implementing car properties directly on the registration for the sake of simplicity.
After further consideration, I've decided to implement Car and Person entities with many-to-one relationships. For the time being, however, there will be new Car and Person entities created for every Registration. In the future, permanent Car and Person entities will allow the software to formally capture co-drivers, and simplify season points calculations, so I'll need to circle back and add those eventually.
Missing fields:
Not specified in the resource manifest, but also need to consider:
Originally specified but declining to implement:
paid (consider a one-to-one Payment entity)participating