Sebastian
Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
http://www.soldevelo.com
Place of registration: Regional Court for the City of
Gdansk KRS: 0000332728, TAX ID:
PL5862240331, REGON: 220828585, Share capital:
60,000.00 PLN
Josh Zamor|josh....@villagereach.org
Senior Software Development Engineer, OpenLMIS Architect
VillageReach Starting
at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
DIRECT: 1.206.512.1501 CELL: 1.847.504.7262 FAX: 1 206.860.6972
SKYPE: josh.zamor.vr
www.villagereach.org
Connect on Facebook, Twitter and
our Blog
On Jan 25, 2017, at 7:58 AM, Sebastian Brudziński <sbrud...@soldevelo.com> wrote:
Hello everyone,
Today I've been investigating OLMIS-1705 that talks about DELETE endpoints not working. The problem with the delete is that it may affect the not-null constraint in another entity, in which case the resulting SQL query will fail. This is wrapped into the DataIntegrityViolationException. As an example, attempting to delete a geographic zone will fail if there's any facility that is currently linked to that geographic zone (because Facility requires non-null geographic zone).
I've been wondering about the approach we want to take to handle those errors. What currently happens is that the delete throws DataIntegrityViolationException, which is translated into 500 error code. We could try to implement manual validations before the actual delete happens, but we've got quite a lot of the not-null constraints scattered across the services and having to check all of the instances of let's say 10 entities upon delete somehow doesn't seem like a good solution. Any ideas for other approaches to tackle this? Or should we just leave it be 500 error code?
Best regards,
Sebastian.
Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.comSolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
http://www.soldevelo.com
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
--
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/5888CB0B.6050305%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.
Hello,
although it's true that we won't have foreign key issues in this
case, I think we would still don't want archived geographic zones
being referenced by active facilities? There might be no hard
database integrity error, however we might get a logical integrity
error in this case. Do you think this is something we should
consider?
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/BDB8ACA4-6F39-4FF7-90F3-F7AE23B39214%40villagereach.org.
For more options, visit https://groups.google.com/d/optout.
Software Developer / Team Leader
Thanks for the answer Josh.
From what you are saying, the DELETE should be more of an
"archive", rather than actual remove from the system. Does that
mean we do not want to support complete removal at all? I think
that raises some more questions.
What does it mean that a facility is associated with a geographic
zone that is marked as deleted? Does this mean that the facility
does no longer has got that association? If so, it would be
simpler to just remove all non-null constraints and deletes would
work just fine as well. However, I believe we actually want to
have those checks in place? Or would we treat them as an
association that still exists but with an archived resource? If
so, do we still consider that association valid? Is it kind of -
it doesn't matter that this resource is archived now, it existsed
in the past so it's OK?
About discovering the resource via "/search", this is probably correct when creating new resources. However all the existing instances will simply look for a resource using UUIDs (especially cross-service relationships). In that case they would just fetch the "archived" resources they are linked to. Is that what we want to happen for all of our cross-service associations?
From what I understand, this approach means revisiting all our
searches and introducing the checks for the deleted/archived flag
+ an option to search for archived resources. We will probably
need to revisit our unique constraints as well (we may have
duplications if we keep archived instances). Is that refactor
something that we want to do in 3.0 for all of our services?
Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41
Al. Zwycięstwa 96/98 81-451,
Gdynia
http://www.soldevelo.com
Place of registration: Regional Court for the City of
Gdansk KRS: 0000332728, TAX ID: PL5862240331,
REGON: 220828585,
Share capital: 60,000.00 PLN
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/BDB8ACA4-6F39-4FF7-90F3-F7AE23B39214%40villagereach.org.
Josh Zamor|josh....@villagereach.org
Senior Software Development Engineer, OpenLMIS Architect
VillageReach Starting
at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
DIRECT: 1.206.512.1501 CELL: 1.847.504.7262 FAX: 1 206.860.6972
SKYPE: josh.zamor.vr
www.villagereach.org
Connect on Facebook, Twitter and
our Blog
On Jan 25, 2017, at 11:11 AM, Sebastian Brudziński <sbrud...@soldevelo.com> wrote:
Thanks for the answer Josh.
From what you are saying, the DELETE should be more of an "archive", rather than actual remove from the system. Does that mean we do not want to support complete removal at all? I think that raises some more questions.
What does it mean that a facility is associated with a geographic zone that is marked as deleted? Does this mean that the facility does no longer has got that association? If so, it would be simpler to just remove all non-null constraints and deletes would work just fine as well. However, I believe we actually want to have those checks in place? Or would we treat them as an association that still exists but with an archived resource? If so, do we still consider that association valid? Is it kind of - it doesn't matter that this resource is archived now, it existsed in the past so it's OK?
About discovering the resource via "/search", this is probably correct when creating new resources. However all the existing instances will simply look for a resource using UUIDs (especially cross-service relationships). In that case they would just fetch the "archived" resources they are linked to. Is that what we want to happen for all of our cross-service associations?
From what I understand, this approach means revisiting all our searches and introducing the checks for the deleted/archived flag + an option to search for archived resources. We will probably need to revisit our unique constraints as well (we may have duplications if we keep archived instances). Is that refactor something that we want to do in 3.0 for all of our services?
Best regards,
Sebastian.--
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/a620c1fb-56b0-fb4e-e69d-318a048aab05%40soldevelo.com.
Office: +48 58 782 45 40/ Fax: +48 58 782 45 41Al. Zwycięstwa 96/9881-451, Gdynia
http://www.soldevelo.com
Place of registration: Regional Court for the City of GdanskKRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,Share capital: 60,000.00 PLN
Office: +48 58 782 45 40/ Fax: +48 58 782 45 41Al. Zwycięstwa 96/9881-451, Gdynia
http://www.soldevelo.com
Place of registration: Regional Court for the City of GdanskKRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,Share capital: 60,000.00 PLN
--
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/5888CB0B.6050305%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.
--
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/BDB8ACA4-6F39-4FF7-90F3-F7AE23B39214%40villagereach.org.
For more options, visit https://groups.google.com/d/optout.
--
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/a620c1fb-56b0-fb4e-e69d-318a048aab05%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.
--
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/765B70FF-DC5A-4829-A518-6F3DBD4EA230%40villagereach.org.
Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41
Al. Zwycięstwa 96/98 81-451,
Gdynia
http://www.soldevelo.com
Place of registration: Regional Court for the City of
Gdansk KRS: 0000332728, TAX ID: PL5862240331,
REGON: 220828585,
Share capital: 60,000.00 PLN
Hi Sebastian and Josh,
For the RequisitionTemplate DELETE endpoint, I suggest we simply prohibit deletion of any RequisitionTemplate that has 1 or more Requisitions. That should involve adding a simple check before deletion and responding with a 400 status code* and an error message.
For RequisitionTemplate I don’t think we need to do the complex thing of marking a deleted item as “Archived”. If there are zero Requisitions, then we truly allow the user to delete the RequisitionTemplate altogether, and that is sufficient. This is not one of our high-value endpoints where we want to archive old records or store a long audit trail. I don’t think an “Archived” status for RequisitionTemplate data is worth the complexity.
*HTTP 422 could also appropriate. OpenLMIS service style guide points to this: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#http-status . I don’t think we have any consistency yet about what to return when DELETEs are not allowed. So I’m fine with 400 or 422.
Sebastian, this ticket 1705 seems to touch a lot of components and it has a lot of different DELETE endpoints to address. If we should split the ticket to address different services/components on their own, that’s fine. Also, if it would help to have a Skype meeting to speed up our decision-making, feel free to schedule.
-Brandon
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/588B5C04.10403%40soldevelo.com.
Josh Zamor|josh.zamor@villagereach.org
Josh Zamor|josh.zamor@villagereach.org
Senior Software Development Engineer, OpenLMIS Architect
VillageReach Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
DIRECT: 1.206.512.1501 CELL: 1.847.504.7262 FAX: 1 206.860.6972
SKYPE: josh.zamor.vr
www.villagereach.org
Connect on Facebook, Twitter and our Blog
On Jan 25, 2017, at 7:58 AM, Sebastian Brudziński <sbrud...@soldevelo.com> wrote:
Hello everyone,
Today I've been investigating OLMIS-1705 that talks about DELETE endpoints not working. The problem with the delete is that it may affect the not-null constraint in another entity, in which case the resulting SQL query will fail. This is wrapped into the DataIntegrityViolationException. As an example, attempting to delete a geographic zone will fail if there's any facility that is currently linked to that geographic zone (because Facility requires non-null geographic zone).
I've been wondering about the approach we want to take to handle those errors. What currently happens is that the delete throws DataIntegrityViolationException, which is translated into 500 error code. We could try to implement manual validations before the actual delete happens, but we've got quite a lot of the not-null constraints scattered across the services and having to check all of the instances of let's say 10 entities upon delete somehow doesn't seem like a good solution. Any ideas for other approaches to tackle this? Or should we just leave it be 500 error code?
Best regards,
Sebastian.--
Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.comSolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40/ Fax: +48 58 782 45 41Al. Zwycięstwa 96/9881-451, Gdynia
http://www.soldevelo.com
Place of registration: Regional Court for the City of GdanskKRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,Share capital: 60,000.00 PLN
--
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/5888CB0B.6050305%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.
--
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/BDB8ACA4-6F39-4FF7-90F3-F7AE23B39214%40villagereach.org.
For more options, visit https://groups.google.com/d/optout.
--
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/a620c1fb-56b0-fb4e-e69d-318a048aab05%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.
--
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/765B70FF-DC5A-4829-A518-6F3DBD4EA230%40villagereach.org.
For more options, visit https://groups.google.com/d/optout.
--
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.
Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41
Al. Zwycięstwa 96/98 81-451,
Gdynia
http://www.soldevelo.com
Place of registration: Regional Court for the City of
Gdansk KRS: 0000332728, TAX ID: PL5862240331,
REGON: 220828585,
Share capital: 60,000.00 PLN
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/166a251c-ddbd-4493-a637-331e01a811e1%40googlegroups.com.