search

codyjmcb / golf_stuff

0 stars 1 forks source link

Update database tables to have NON-NULL fields where applicable #19

Open codyjmcb opened 1 month ago

codyjmcb commented 1 month ago

See Database ReadMe.txt

codyjmcb commented 1 month ago

27 related

iiiancampbell commented 1 month ago

Happy to take this one too @codyjmcb . I'll amend the database readme's existing tables with the appropriate data types

codyjmcb commented 1 month ago

@iiiancampbell This one I'm not sure you'll be able to do until I can figure out #35 ... This issue more pertains to updating the DB schema as it exists on the server (rasp pi), and I'm not sure yet how (if possible) to get the schema tracked by git. I'm also investigating another thing, and that's setting up the rasp pi for remote development (non-local network), this issue requires access to the rasp pi.

codyjmcb commented 1 month ago

Moving this here bc its helpful information:

I can see why this one is confusing because of the previous one. But nullable in this context is referring to whether a field is required to create an entry in the database. For example, in the screenshot, golferid is NOT NULLABLE, which means that that field is required to create a DB entry, but the other fields are not required... This doesn't make sence for some of the fields within the database, as a golfer must have a first name, etc.

image

iiiancampbell commented 1 month ago

Oops, misread the issue then! Just deleted my branch and PR. After re-reading, yeah I'll have to spin up the DB locally to get to this issue.

Noted on the above.

Is it worth making firstname/lastname required as well for end user case/useability? I imagine this info would be supplementary to golferID as in - realistically, a persons name will always be entered and used when dealing with the person, but when manipulating the persons object on the backend, the golferID would be used?

codyjmcb commented 1 month ago

Yes absolutely!! The DB I've stood up for this most recent attempt at this uses the same tables as described in the ReadMe, but a lot of the fields are NULLABLE (where the document states that they are NOT NULLABLE). So this issue pertains to updating the tables in the DB to include NOT NULLABLE where it makes sense (name for example, course name for another). Ideally the client applications validate that fields are filled in appropriately, and the NOT NULLABLE fields ensure that the constraints were enforced properly.