Inconsistency in repository layer

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

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ł


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

···

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.

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 openlmis-dev@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

     palbecki@soldevelo.com

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


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

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.


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

···

On Wed, May 2, 2018 at 5:06 PM, josh.zamor@openlmis.org wrote:

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


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

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 openlmis-dev@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

     palbecki@soldevelo.com