task/3382: Harmonisera tabellnamn #6
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "task/3382"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
task/3382: Harmonisera tabellnamn (Work in progress)to WIP: task/3382: Harmonisera tabellnamnCode Standard:
Annotation value assignment, shall equals sign have space around or not? Code style is not consistent within SciPro.
I would prefer with spaces (first option).
WIP: task/3382: Harmonisera tabellnamnto task/3382: Harmonisera tabellnamnBranch needs to be updated against latest develop
All the re-ordering of things is making it very difficult to review the actual changes made. Please avoid doing this in the future or, at the very least, do the re-ordering in a separate commit that can be ignored when viewing the changes.
While I appreciate the effort of re-organizing and cleaning up the code it should have been done in, at the very least, separate commits. Ideally with automated tooling to adhere to the formatting/organization established so that it is easy to maintain in the future.
But when it was done interspersed with the actual changes it made the pull request way bigger and harder to review than it had to be.
With that said it is still admirable work and something that was long overdue. I noticed you also fixed some plural to singular form to make it even more uniform.
There are a couple of user related foreign keys where I think the new column name lost some useful contextual information that I think should be fixed. There are many other columns that are named
user_id
but they were named that way beforehand as well so I'm ignoring those. Most columns were changed to<context>_user_id
which is a good name but a few were changed from<context>_id
to justuser_id
which I'm not a fan of.If you could fix those couple of columns it looks good to me.
I ran the migrations against an empty schema and noticed foreign key names were mismatched with earlier migrations but they instead matched against what is in production. I've manually corrected the names in production and pushed a fix for the migration script to use the expected names based on earlier migrations.
I've clicked on basically every page in SciPro and they all work.
@ -55,0 +72,4 @@
private Checklist checklist;
@OneToOne(optional = true, cascade = CascadeType.ALL)
@JoinColumn(name = "file_reference_id", referencedColumnName = "id")
This feels like a downgrade in terms of documentation from the column name.
file_upload_reference_id
tells you that it is an uploaded file to the activity whilefile_reference_id
conveys no such information.It's renamed to 'upload_file_reference_id', following the same scheme _user_id. "file_reference" is the table name.
@ -53,1 +51,3 @@
}
//<editor-fold desc="JPA-mappings of foreign keys in this table (activity_plan_template) referencing other tables.">
@ManyToOne(optional=false)
@JoinColumn(name = "user_id")
Again less self describing column name.
creator_id
tells you it is the user who created the template rather than just a genericuser_id
. The referenced table/type is visible from the foreign key/class.@ -31,3 +51,4 @@
private List<String> questions = new ArrayList<>(1);
@ManyToOne(optional = false)
@JoinColumn(name = "user_id")
Less self describing column name.
creator_id
tells you it is the user who created the template rather than just a genericuser_id
. The referenced table/type is visible from the foreign key/class.@ -59,0 +95,4 @@
* to delete the document
*/
@OneToOne(cascade = CascadeType.ALL)
@JoinColumn(name = "file_reference_id", referencedColumnName = "id")
Less self describing column name.
document_reference_id
tells you something extra rather than just a genericfile_reference_id
. The referenced table/type is visible from the foreign key/class. Each seminar also has multiple documents related to it so a better name is useful. Especially since the columndocument_upload_date
references some "document" but there is no document file column.@ -16,12 +16,14 @@ public class Comment extends DomainObject {
private Long id;
@ManyToOne(optional = false)
@JoinColumn(name = "user_id")
The renaming of some user foreign key columns seem a bit weird. In some places it was a loss of information by going to just
user_id
while others they got_user_id
appended to them and some were left as-is. Out of the three options justuser_id
is the worst one when there is additional context to be had. In this case "creator", so I think the column should becreator_id
orcreator_user_id
to convey as much information as possible. It is also consistent with other foreign keys that use the<context>_user_id
naming scheme. See for examplecore/src/main/java/se/su/dsv/scipro/peer/PeerRequest.java
and itsrequester_user_id
.@ -18,3 +20,3 @@
private boolean enabled = false;
@Basic
@Column(name = "user_name")
Username is one word. "User name" is the user's name (as in John Doe) while username is the unique
john@doe.example
.@ -22,3 +21,3 @@
@ManyToOne(optional = false)
@JoinColumn(name = "reviewer_id", nullable = false)
@JoinColumn(name = "user_id", nullable = false)
Loss of information in the column name, should be
reviewer_user_id
.@ -6,3 +6,3 @@
@Entity
@Cacheable(true)
@Table(name="username", uniqueConstraints={@UniqueConstraint(columnNames={"username"})})
@Table(name="user_name", uniqueConstraints={@UniqueConstraint(name = "uk_user_name", columnNames={"user_name"})})
Username is one word, not two. User name is a user's name (John Doe) while username is their unique identifier
john@doe.example
.@ -12,3 +12,3 @@
private Long id;
@Basic(optional=false)
@Column(name = "user_name", nullable = false)
Username is one word, not two. User name is a user's name (John Doe) while username is their unique identifier
john@doe.example
.Looks good.