task/3382: Harmonisera tabellnamn #6

Merged
ansv7779 merged 104 commits from task/3382 into develop 2024-11-12 13:33:44 +01:00
2 changed files with 18 additions and 6 deletions
Showing only changes of commit c833426a69 - Show all commits

View File

@ -1,9 +1,19 @@
package se.su.dsv.scipro.peer; package se.su.dsv.scipro.peer;
import jakarta.persistence.Basic;
import jakarta.persistence.Cacheable;
import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;
import jakarta.persistence.JoinColumn;
import jakarta.persistence.Lob;
import jakarta.persistence.ManyToOne;
import jakarta.persistence.Table;
import se.su.dsv.scipro.system.DomainObject; import se.su.dsv.scipro.system.DomainObject;
import se.su.dsv.scipro.system.User; import se.su.dsv.scipro.system.User;
import jakarta.persistence.*;
import java.io.Serializable; import java.io.Serializable;
import java.util.Comparator; import java.util.Comparator;
tozh4728 marked this conversation as resolved Outdated

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 just user_id is the worst one when there is additional context to be had. In this case "creator", so I think the column should be creator_id or creator_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 example core/src/main/java/se/su/dsv/scipro/peer/PeerRequest.java and its requester_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 just `user_id` is the worst one when there is additional context to be had. In this case "creator", so I think the column should be `creator_id` or `creator_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 example `core/src/main/java/se/su/dsv/scipro/peer/PeerRequest.java` and its `requester_user_id`.
@ -16,14 +26,16 @@ public class Comment extends DomainObject {
private Long id; private Long id;
@ManyToOne(optional = false) @ManyToOne(optional = false)
@JoinColumn(name = "user_id") @JoinColumn(name = "creator_user_id", referencedColumnName = "id")
private User creator; private User creator;
@Basic
@Column(name = "comment")
@Lob @Lob
private String comment; private String comment;
@ManyToOne(optional = false) @ManyToOne(optional = false)
@JoinColumn(name = "comment_thread_id") @JoinColumn(name = "comment_thread_id", referencedColumnName = "id")
private CommentThread commentThread; private CommentThread commentThread;
protected Comment() { protected Comment() {

View File

@ -538,11 +538,11 @@ alter table comment_thread rename column `commentableKey` to `commentable_key`;
alter table `comment_thread` add constraint uk_comment_thread_id_key unique(commentable_id, commentable_key); alter table `comment_thread` add constraint uk_comment_thread_id_key unique(commentable_id, commentable_key);
alter table comment rename column `commentThread_id` to `comment_thread_id`; alter table comment rename column `commentThread_id` to `comment_thread_id`;
alter table comment rename column `creator_id` to `user_id`; alter table comment rename column `creator_id` to `creator_user_id`;
alter table `comment` alter table `comment`
add constraint fk_comment_user_id add constraint fk_comment_creator_user_id
foreign key (user_id) references user (id) foreign key (creator_user_id) references user (id)
on delete cascade on update cascade; on delete cascade on update cascade;
alter table `comment` alter table `comment`