Inconsistency in repository layer

[Mateusz Kwiatkowski]

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

[Paweł Albecki]

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ł

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/cf8f7026-265e-4388-8493-71d0743444c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Paweł Albecki
Software Developer
palb...@soldevelo.com

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

[josh....@openlmis.org]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/cf8f7026-265e-4388-8493-71d0743444c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Paweł Albecki
Software Developer
palb...@soldevelo.com

[Paweł Albecki]

In the example you provided, I don't understand why would you want check for null only. The code won't work as expected if you change it. 

I'm also for making a style guide. Both Confluence or direct commit to Git are fine. Do what you think would be smoother.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8914d4e4-6020-4cb5-85dd-a1c8ea0b3be9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Paweł Albecki
Software Developer
palb...@soldevelo.com