-
Notifications
You must be signed in to change notification settings - Fork 429
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
Use map for mod_mam:message_row() #3093
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3093 +/- ##
==========================================
- Coverage 79.08% 79.03% -0.06%
==========================================
Files 386 387 +1
Lines 31829 31838 +9
==========================================
- Hits 25172 25163 -9
- Misses 6657 6675 +18
Continue to review full report at Codecov.
|
fe97255
to
2787246
Compare
2787246
to
e08c405
Compare
7ad1cec
to
ba664d7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very very good, just a few comments in the tests 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally love it. It has a theoretical impact on performance, but it's probably just theoretical. This is one of the cases where flexibility outweighs those tiny nanoseconds. And this is a very useful one to me 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I have a few comments and Elvis has two that I agree with:
mod_mam.erl 460 1 warning invalid_dynamic_call Remove the dynamic function call on line 460. Only modules that define callbacks should make dynamic calls. (lsp)
mod_mam.erl 617 1 warning line_length Line 617 is too long: message_row_to_xml(MamNs, #{id := MessID, jid := SrcJID, packet := Packet}, QueryID, SetClientNs) ->. (lsp)
src/mam/mam_lookup.erl
Outdated
@@ -158,7 +158,8 @@ decode_rows(MessageRows, Env) -> | |||
[decode_row(Row, Env) || Row <- MessageRows]. | |||
|
|||
%% First element of the tuple is decoded message ID |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no tuple now, please amend this comment.
src/mam/mod_mam.erl
Outdated
@@ -119,7 +118,7 @@ | |||
|
|||
-type borders() :: #mam_borders{}. | |||
|
|||
-type message_row() :: {message_id(), jid:jid(), exml:element()}. | |||
-type message_row() :: #{id => message_id(), jid => jid:jid(), packet => exml:element()}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are they optional? Could we make the keys mandatory in this type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏽
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit late, but it looks great, thanks for the extra work to address the comments!
This PR addresses "what if we use map, will tests still pass?"
Proposed changes include:
As a dev, I want to extract some extra fields from MAM (or during MAM lookup).
I am currently only allowed to return message-id, source-jid and stanza packet. But sometimes I need to return more fields, so I can format them later (to build a proper forwarded message). Maps allows to attach some meta info to each message.
Also, it's really hard to track what is what in 3 fields tuple