Conversation
…dels' into refactor--domain-models
Changed so response dto comes with uuid
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
To avoid domain and dto models having to import each other
With the exception of position, will implement poisition after studying it more
|
Note: positions domain models and dto models are going to need some change, I do not have a full understanding of them yet. So changes have not been implemented to Positions yet. |
|
Todo:
|
|
Keeping note of this here: An error has appeared. Sending an announcement json: &{123 all 2006-01-04 15:00:00 -0800 PST 1234 124} to http://localhost:8080/v1/announcements The stack dump reads: runtime error: invalid memory address or nil pointer dereference This is an issue with dereferencing a nil pointer somewhere upstream, probably with mapper and how it deals with sql null values. |
|
400 level errors related to bad requests seem common too, needs investigating |
DBmodels are models that should not be known to exist by the CLI and any other internals that want to use them.
This PR introduces a solution to that: DTO and Domain models.
Handlers take in a dto_request model and send it over to services as a domain model. Services then call repository where it can access database operations.
Something I am thinking about: Originally I split dto_requests and dto_response into two modules thinking that we can return the client a specialized dto, if we wanted to hide ID or anything else, I dicided against hiding ID for now, and I have yet to find a use for dto_response. So perhaps we should merge the DTO modules to one to reduce code. Some opinions will be good.