lately I’ve encountered some problem in our repositories. We have a different approach have we are dealing with values passed into our custom methods.
For parameters that are not collections we are omitting them if they are null, which is fine in my opinion, but I’ve also seen cases when we are returning empty result if passed value is null.
For collections we are mostly omitting them in query when they are null or empty, which is not OK in my mind. I would rather include this parameter in query if it is empty, not null, and return empty result list. I’ve seen both of those approaches in our repositories.
I would say that our repository layer should be consistent in this case and our services should deal with our endpoint specific needs. Therefore I would propose adding a short note how we should treat parameters in our repositories.
What do you think about this? Any ideas how we should solve this issue?
I think this is important topic, more consistency means less bugs.
To be honest, it’s hard to catch what are the inconsistencies without seeing some code. Could you present some code snippets that would show our current approaches and how do you see we should standardize it?
On Mon, Apr 30, 2018 at 4:00 PM, Mateusz Kwiatkowski 1stmateusz@gmail.com wrote:
Hi Dev Group,
lately I’ve encountered some problem in our repositories. We have a different approach have we are dealing with values passed into our custom methods.
For parameters that are not collections we are omitting them if they are null, which is fine in my opinion, but I’ve also seen cases when we are returning empty result if passed value is null.
For collections we are mostly omitting them in query when they are null or empty, which is not OK in my mind. I would rather include this parameter in query if it is empty, not null, and return empty result list. I’ve seen both of those approaches in our repositories.
I would say that our repository layer should be consistent in this case and our services should deal with our endpoint specific needs. Therefore I would propose adding a short note how we should treat parameters in our repositories.
What do you think about this? Any ideas how we should solve this issue?
Regards,
Mateusz
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
I’d second this sounds like a good change (style guide perhaps?) though I too would love to see a link to some code examples.
···
On Monday, April 30, 2018 at 7:28:28 AM UTC-7, Paweł Albecki wrote:
Hi Mateusz,
I think this is important topic, more consistency means less bugs.
To be honest, it’s hard to catch what are the inconsistencies without seeing some code. Could you present some code snippets that would show our current approaches and how do you see we should standardize it?
Best regards,
Paweł
On Mon, Apr 30, 2018 at 4:00 PM, Mateusz Kwiatkowski 1stma...@gmail.com wrote:
Hi Dev Group,
lately I’ve encountered some problem in our repositories. We have a different approach have we are dealing with values passed into our custom methods.
For parameters that are not collections we are omitting them if they are null, which is fine in my opinion, but I’ve also seen cases when we are returning empty result if passed value is null.
For collections we are mostly omitting them in query when they are null or empty, which is not OK in my mind. I would rather include this parameter in query if it is empty, not null, and return empty result list. I’ve seen both of those approaches in our repositories.
I would say that our repository layer should be consistent in this case and our services should deal with our endpoint specific needs. Therefore I would propose adding a short note how we should treat parameters in our repositories.
What do you think about this? Any ideas how we should solve this issue?
Regards,
Mateusz
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
I’d second this sounds like a good change (style guide perhaps?) though I too would love to see a link to some code examples.
On Monday, April 30, 2018 at 7:28:28 AM UTC-7, Paweł Albecki wrote:
Hi Mateusz,
I think this is important topic, more consistency means less bugs.
To be honest, it’s hard to catch what are the inconsistencies without seeing some code. Could you present some code snippets that would show our current approaches and how do you see we should standardize it?
Best regards,
Paweł
On Mon, Apr 30, 2018 at 4:00 PM, Mateusz Kwiatkowski 1stma...@gmail.com wrote:
Hi Dev Group,
lately I’ve encountered some problem in our repositories. We have a different approach have we are dealing with values passed into our custom methods.
For parameters that are not collections we are omitting them if they are null, which is fine in my opinion, but I’ve also seen cases when we are returning empty result if passed value is null.
For collections we are mostly omitting them in query when they are null or empty, which is not OK in my mind. I would rather include this parameter in query if it is empty, not null, and return empty result list. I’ve seen both of those approaches in our repositories.
I would say that our repository layer should be consistent in this case and our services should deal with our endpoint specific needs. Therefore I would propose adding a short note how we should treat parameters in our repositories.
What do you think about this? Any ideas how we should solve this issue?
Regards,
Mateusz
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
