Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chat 232 user nickname #79

Closed
wants to merge 7 commits into from
Closed

Chat 232 user nickname #79

wants to merge 7 commits into from

Conversation

LionnoiL
Copy link
Contributor

@LionnoiL LionnoiL commented May 7, 2024

В таблицю message додані поля sender_id та receiver_id. В клас Message поля sender та receiver. Додані поля в MessageResponseDto sentFromNickname та sendToNickname. В LastMessageResponseDto доданий sentFromNickname. Змінений маппер.
Також додав порт 5557 в налаштування серверу тому що 8080 у мене зайнятий.

Troha7 and others added 7 commits March 24, 2024 15:21
* fix: fixed notification and event type

* bugfix: fixed disconnect from websocket. Set time to first message.

* fix: refactored and optimized notifications
* fix: fixed notification and event type

* bugfix: fixed disconnect from websocket. Set time to first message.

* fix: refactored and optimized notifications

* refactor: refactored and optimized request to get all topics
# Conflicts:
#	src/main/java/com/chat/yourway/listener/StompSubscriptionListener.java
#	src/main/java/com/chat/yourway/mapper/NotificationMapper.java
#	src/main/java/com/chat/yourway/model/event/ContactEvent.java
#	src/main/java/com/chat/yourway/service/ContactEventServiceImpl.java
#	src/main/java/com/chat/yourway/service/NotificationServiceImpl.java
#	src/main/java/com/chat/yourway/service/interfaces/ContactEventService.java
#	src/test/java/com/chat/yourway/integration/controller/ChatControllerTest.java
#	src/test/java/com/chat/yourway/unit/service/impl/ContactEventServiceImplTest.java
#	src/test/java/com/chat/yourway/unit/service/impl/NotificationServiceImplTest.java
@LionnoiL LionnoiL self-assigned this May 7, 2024
@LionnoiL LionnoiL added the enhancement New feature or request label May 7, 2024
@LionnoiL LionnoiL requested a review from Troha7 May 7, 2024 07:18
@Troha7
Copy link
Member

Troha7 commented May 7, 2024

Твій спосіб додавання нікнейу до MessageResponseDto буде працювати але на мою думку це оверхед.
Думаю можна було обійтись без такого ускладнення бази данних, бо інформацію про нікнейм відправника (sentFrom) можна отримати один раз при вході в застосунок так можна отримати обєкт ContactResponseDto в якому є nickname.
Нікнейм одержувача в публічних топіках не потрібен бо одержувач це сам топік.

@Column(name = "send_to")
private String sendTo;

@ManyToOne(fetch = FetchType.EAGER)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Краще не використовувати FetchType.EAGER якщо в цьому не має потреби.
https://www.baeldung.com/hibernate-lazy-eager-loading

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

так. тут була помилка при завантаженні тому так поставив.

@@ -81,6 +84,8 @@ public MessageResponseDto createPrivate(MessagePrivateRequestDto message, String
Message savedMessage = messageRepository.save(Message.builder()
.sentFrom(email)
.sendTo(message.getSendTo())
.sender(contactService.findByEmail(email))
.receiver(contactService.findByEmail(message.getSendTo()))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

При зберіганні кожного повідомлення будуть робитись два додаткові запити до бази данних що не є добре для перформенсу застосуну.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

contactService.findByEmail закешований, тому запитів в базу не буде.

@LionnoiL
Copy link
Contributor Author

LionnoiL commented May 8, 2024

Твій спосіб додавання нікнейу до MessageResponseDto буде працювати але на мою думку це оверхед. Думаю можна було обійтись без такого ускладнення бази данних, бо інформацію про нікнейм відправника (sentFrom) можна отримати один раз при вході в застосунок так можна отримати обєкт ContactResponseDto в якому є nickname. Нікнейм одержувача в публічних топіках не потрібен бо одержувач це сам топік.

Ти маєш на увазі отримання інформації про топік /topics/{id} де є список всіх контактів чи якісь інший метод? Тобто коли в топіку буде переписка з, наприклад, 1000 контактів ми при отриманні просто заголовку топіку отримаємо всі контакти. Це не оверхед? Гадаю що оверхед в реляційній базі даних це sent_from або send_to в message. Також не зрозумів навіщо зберігати що юзер був колись підписаний на топік. Де ця історія використовується крім того що потрібно отримати його контакт в топіку?
Стосовно нікнейма в MessageResponseDto: приватне повідомлення суміщене з публічним тому так вийшло. В публічних повідомленнях receiver буде null. Можна ще звичайно зробити окремо на приватне PrivateMessageResponseDto.

@Troha7
Copy link
Member

Troha7 commented May 8, 2024

Я маю на увазі те що не обовязково змінювати базу данних якщо треба змінити лише обєкт MessageResponseDto.
Як на мене простіше змінити MessageResponseDto перед відправкою його на фронт по WebSocket.
Це можна зробити в классі ChatMessageServiceImpl
nikname
nikname2
Ось результат
nikname_res

sent_from та send_to в message необхідні для отримання історії переписки для відображення хто і кому писав в чаті.

"Також не зрозумів навіщо зберігати що юзер був колись підписаний на топік." Якщо ти про це
Screenshot from 2024-05-08 22-17-39
То це для щоб робити перевірку чи юзер ще підписаний на топік та в майбутньому використовувати історію його підписок (Але ти правий це оверхед воно майже не використовується - можешь видалити якщо хочешь)

@LionnoiL
Copy link
Contributor Author

LionnoiL commented May 8, 2024

я не згоден з тим що при виводі повідомлення ми кожного разу будемо отримувати його через пошук по email краще ніж один раз зберегти id в базу при створенні повідомлення. вибач, можливо я намагаюсь виправити вже створенну архітектуру бази даних чи застосунку, але робити костилями я не можу. переасайню таску на тебе. твій варіант краще підійде.

@LionnoiL LionnoiL closed this May 8, 2024
@Troha7
Copy link
Member

Troha7 commented May 9, 2024

Можливо це не найкращий варіант але не хотілося б змінювати структуру бази данних через нікнейм, тим паче пошук по email вже закешований.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants