TRUNK-2497: Design specification

Hi devs

I would like your input on this ticket am working on TRUNK-2497. The ticket description says when a message sent using the MessageService api in core, it should be persisted in a table called sent_messages with the column names as specified on the ticket. The table is suppose to look like this

. Now my question is…

  1. In cases where the same message is sent to multiple users, how do i store such a message, since the receiver_id column can only take one user id

  2. In some of the sendMessage methods of MessageService, no User object or user id of the sender or receiver is been passed, only the email of the receiver. I know i can get the user id of the sender by calling Context.getUserService().getAuthenticatedUser(), but how do i get the id or user object of the receivers knowing only their emails.

I had this questions since before starting implementation of the ticket, but i had a work around(not necessary a work around, just don’t know how to put it :slight_smile: ). When designing the sent_message table i declared the receiver_id as nullable, so i did not worry about any of the questions above, but now @dkayiwa requested that i add a foreign key constraint to both the sender and the receiver id, and since null fields will violate the foreign key constraints i am now forced to ask this question. Also aside from that storing null in the receiver_id column does not make much sense.

Remove sender_id from this table and create a new one:

message_receiver( message_id, receiver_id) where the PK is (message_id + receiver_id), and both columns are FK to the corresponding tables. If there are specific attributes relative to the message and the receiver, put them here (perhaps sent_date ?).

Check if there’s an API method that retrieves a User by e-mail address.

1 Like

When implementing this, should i create a domain object MessageReceiver so that i make use of hibernate mappings and data access objects. That is when saving a sent message calling dao.saveSentMessage() i could also call some to be implemented dao.saveMessageReceiver(). Or when saving a message using dao.saveSentMessage(message) i can just write some sql querries to save the received messages in their own table.

I guess so, to be consistent with the architecture of the data layer. Native SQL is just for special cases.

I won’t use a new DAO, it’s a weak entity so you can use the same service/DAO of the Message entity.