Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
There are several database columns which should be set NOT NULL. As well, nullable columns do not need 'not null' => FALSE
because that is the default.
Original report
I have noticed some potential improvements that can be made to the database schema:
- {election_vote} does not need to store election_id or post_id. It can get those by joining to {election_ballot}.
- There are a bunch of fields that can set NOT NULL:
- {election_post}: election_id, title, changed
- {election_vote}: election_id, post_id, ballot_id
- {election_ballot}: election_id, post_id, uid
- {election}: title, uid, changed
- {election_candidate}: post_id, election_id, changed
- On columns where NULL is permitted, the column comment should state what it means for the column to be NULL.
I would be happy to write a patch once we have agreement about the changes.
Comments
Comment #2
pjcdawkins CreditAttribution: pjcdawkins commentedPlease allow for the possibility of setting election_vote.ballot_id NULL, and still being able to count votes. It's to theoretically allow counting the entire election's votes without having any trace of who voted, which means you could support #2006326: Make election_vote records anonymous if you wanted. So, that's also why election_vote.ballot_id should not be NOT NULL.
I'm OK with the rest.
There are probably excessive indexes on some tables.
Comment #3
Liam MorlandAh, good point. Yes, best to leave those columns in and leave ballot_id able to be NULL. I'll work on a patch for the rest.
Comment #4
Liam MorlandThe third bullet, documentation of NULLs, will be handled in #2621482: Document NULLs in schema.
Comment #5
Liam MorlandThe patch also removes "'not null' => FALSE," because that is the default.
Comment #6
Liam MorlandThis update patch includes a couple more columns declared NOT NULL.
Comment #7
Liam MorlandUpdated version leaves election_ballot.uid nullable to allow for anonymous voting, allowing #2006326: Make election_vote records anonymous.
Comment #8
Liam MorlandReroll.
Comment #9
Liam MorlandComment #10
pjcdawkins CreditAttribution: pjcdawkins commentedI certainly would not make these database schema choices again if redesigning the module.
However, this is a complex and relatively risky patch, which could break existing installs if they had set these columns NULL before (for whatever reason).
So we'd at least need a clear explanation of the practical benefits.
To me this would imply that if a user is deleted, all their elections must be deleted. I don't think site owners necessarily want that.
Philosophically at least, NULL here would mean that the election has not been changed since it was created.
Candidates are not deleted when posts are deleted - this is explicitly set to NULL in election_candidate_entity_delete().
Comment #11
pjcdawkins CreditAttribution: pjcdawkins commentedI suggest documentation (#2621482: Document NULLs in schema) is more important than actually setting these NOT NULL.
Comment #12
Liam MorlandI was thinking that columns which should be NOT NULL should be set that way, then the others can be documented.
I think normally modified dates are the same as created date for items that have never been edited.
I will re-roll this.
Comment #13
Liam MorlandComment #14
Liam MorlandHi, Patrick, Do you have any feedback about the patch in #13? If you don't want to make any schema changes, then we should move on to #2621482: Document NULLs in schema. It just makes sense to me that we make any desired columns NOT NULL before we try to document the meaning of NULLs.
Comment #15
Liam MorlandComment #17
Liam MorlandReroll.
Comment #19
Liam Morland