fix: add count_by #40
Conversation
asyncmind0
commented
Mar 16, 2020
asyncmind0
commented
- use sumo_utils:is_datetime
- hanndle undefined values
- use sumo_utils:is_datetime - hanndle undefined values
src/sumo_store_riak.erl
Outdated
| count_by(DocName, [], State) -> | ||
| count(DocName, State); | ||
| count_by(_DocName, _Conditions, #{conn := _Conn} = _State) -> | ||
| 0. |
There was a problem hiding this comment.
This should only have 2 spaces for indentation.
There was a problem hiding this comment.
Let's move this function to the API section; below count.
On the other hand, I don't really see the point of having this function, at least I don't see specific logic with the conditions, for example, if condition list if empty, bypass to count(DocName, State), otherwise return 0. This looks to me like a very specific logic. Could you please elaborate more on this, what is the purpose of having this function implemented in this way? What if we have conditions, should we perform the count query based on the conditions?
There was a problem hiding this comment.
currrrently I'm just getting the code to compile and run, I'm not sure how to implement a count_by in the context, maybe I could do a search and get the count ?
There was a problem hiding this comment.
currrrently I'm just getting the code to compile and run, I'm not sure how to implement a count_by in the context, maybe I could do a search and get the count ?
Sorry, I cannot help much here since I haven't worked with Riak a long time ago, but I'd review RiakKV doc and see what would be the best way for implementing this, maybe investigate if there are examples or other cases where this has been implemented already.
Once you have some implementation done, we can review it! Looking forward to that 😉
There was a problem hiding this comment.
To be fair… it's been a long time since we did a proper round of maintenance around inaka projects and that's why none of them use any formatter, or hank, or any other new rebar3 plugin. But, if we're going to start adding those things, we'll always try to use first the ones that we developed and/or choose the ones that are more flexible.
|
|
||
| %% == Plugins == | ||
|
|
||
| {plugins, [steamroller]}. |
There was a problem hiding this comment.
Since this is an inaka project, on principle, we should use rebar3_format instead of steamroller.
In any case, you can either…
- Fork the project and use
steamrolleron your fork. - Use
rebar3_formatwith a profile for you that uses thesr_formatterformatter (that one formats the code withsteamroller).
There was a problem hiding this comment.
I wasn't aware of rebar3_format, let me check it out, Thanks
There was a problem hiding this comment.
This is totally off-topic, but it's something that I always wonder about…
As a maintainer of multiple open-source tools for the Erlang community (and a blog), I'm always trying to reach as many Erlang devs as possible with the news.
So, 100% out of curiosity and not as a criticism: If you didn't know about rebar3_format but you knew about steamroller… How do you get your news about Erlang and its ecosystem? What communication channel am I missing?
I mean… as far as I know, @dtip published steamroller in exactly the same places I published rebar3_format (sometimes even I was the one publishing his work). So… If you don't mind… What did I miss? How can I improve the broadcasting of news about the tools I create/maintain?
There was a problem hiding this comment.
Might be because I searched for "opinionated code formatter for erlang"
coming from python as a python dev, I discovered the comfort of black for python
wanted the same for Erlang
Mostly I'm searching for concepts parallel to python
There was a problem hiding this comment.
Opinionated formatters are the right choice 😉
