Why do we need to update related records in an after trigger but not before?












1















Why do we need to write the logic to update a related record in an after trigger but not before? Update triggers(Before/After) will have both the record ID and the related record's ID so why can I not write the logic in a before trigger?










share|improve this question



























    1















    Why do we need to write the logic to update a related record in an after trigger but not before? Update triggers(Before/After) will have both the record ID and the related record's ID so why can I not write the logic in a before trigger?










    share|improve this question

























      1












      1








      1








      Why do we need to write the logic to update a related record in an after trigger but not before? Update triggers(Before/After) will have both the record ID and the related record's ID so why can I not write the logic in a before trigger?










      share|improve this question














      Why do we need to write the logic to update a related record in an after trigger but not before? Update triggers(Before/After) will have both the record ID and the related record's ID so why can I not write the logic in a before trigger?







      apex trigger before-trigger after-trigger






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Mar 21 at 12:22









      User2529User2529

      338522




      338522






















          2 Answers
          2






          active

          oldest

          votes


















          4














          If I understand your question correctly, then you actually can take your related record update logic and put it in either a before or after trigger.



          Salesforce's suggestion is that before triggers should be used to update data on the records taking part in the trigger (the ones stored in trigger context variables), but it's just that... a suggestion.



          Keeping updates of related objects in after triggers (or not in before triggers) has a few benefits:




          • Following this advice helps logically separate the work done on object X itself, and the work done on the records Y and Z that are related to X

          • If you run into an issue (null pointer exceptions, validation exceptions, etc...) in a before trigger (or more accurately, before the after trigger is run), and have related record update logic in an after trigger, then you potentially won't spend time doing more work that will just be rolled back (compared to if your related record update logic were in a before trigger)

          • Related to the above point, this "fail fast" mechanism (and not doing ultimately meaningless work) means that you have less chance of running out of one of the resources monitored by the governor limits (which could end up masking another error).


          Another reason to avoid updating related records in before triggers is that related records can't take advantage of the "free update" that's available in before triggers (when making a change to a record stored in trigger.new and/or trigger.newMap)



          Conclusion:



          You could put your related record update logic into a before trigger, but you should think long and hard about whether or not that's really a good idea.






          share|improve this answer
























          • Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

            – sfdcfox
            Mar 21 at 13:55











          • @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

            – Derek F
            Mar 21 at 14:11






          • 1





            Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

            – sfdcfox
            Mar 21 at 14:15



















          3














          Using the after trigger event is strongly recommended, but not necessary, for updating related records, because before trigger events can modify the records in an unpredictable order. Waiting until the records have been committed to the database reduces this possibility. Note that there are some specific scenarios where it is even desirable to work with related records in a before trigger, such as if you want to create parent records if they are missing.



          As a simple example, consider these two "triggers" (pseudo-code) that deal with contacts:



          trigger CreateGuid on Contact (before insert) {
          ContactTriggerHelper.createGuidsForContacts(Trigger.new);
          }




          trigger UpdateGuidList on Contact (before insert) {
          ContactTriggerHelper.updateGuidOnAccounts(Trigger.new);
          }




          If CreateGuid runs first, the Account will show the correct values by the end of the transaction. However, if UpdateGuidList runs first, the values will still be null. We cannot strictly predict ahead of time which trigger will run first.



          However, if we move UpdateGuidList to an after insert event, we guarantee that the contacts will have the correct data before the update to the related records occur. This is generally desirable behavior.



          As an alternative to this problem, what if one trigger automatically assigns a value to the lookup field, and another updates the record? In that case, the wrong record could get updated, and it would be troublesome to even debug, because the order of operations are not guaranteed between trigger events that occur at the same time.





          Unless you know for sure that nobody will ever depend on the order of operations of the triggers, or that the order of execution does not matter, stick with the after trigger event for updating related records. It is much easier to use after trigger events all the time and not have to guess about possible side effects than it is to risk random or periodic logic failures because someone did not take your trigger into account when adding more logic elsewhere.






          share|improve this answer























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "459"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f254752%2fwhy-do-we-need-to-update-related-records-in-an-after-trigger-but-not-before%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            4














            If I understand your question correctly, then you actually can take your related record update logic and put it in either a before or after trigger.



            Salesforce's suggestion is that before triggers should be used to update data on the records taking part in the trigger (the ones stored in trigger context variables), but it's just that... a suggestion.



            Keeping updates of related objects in after triggers (or not in before triggers) has a few benefits:




            • Following this advice helps logically separate the work done on object X itself, and the work done on the records Y and Z that are related to X

            • If you run into an issue (null pointer exceptions, validation exceptions, etc...) in a before trigger (or more accurately, before the after trigger is run), and have related record update logic in an after trigger, then you potentially won't spend time doing more work that will just be rolled back (compared to if your related record update logic were in a before trigger)

            • Related to the above point, this "fail fast" mechanism (and not doing ultimately meaningless work) means that you have less chance of running out of one of the resources monitored by the governor limits (which could end up masking another error).


            Another reason to avoid updating related records in before triggers is that related records can't take advantage of the "free update" that's available in before triggers (when making a change to a record stored in trigger.new and/or trigger.newMap)



            Conclusion:



            You could put your related record update logic into a before trigger, but you should think long and hard about whether or not that's really a good idea.






            share|improve this answer
























            • Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

              – sfdcfox
              Mar 21 at 13:55











            • @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

              – Derek F
              Mar 21 at 14:11






            • 1





              Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

              – sfdcfox
              Mar 21 at 14:15
















            4














            If I understand your question correctly, then you actually can take your related record update logic and put it in either a before or after trigger.



            Salesforce's suggestion is that before triggers should be used to update data on the records taking part in the trigger (the ones stored in trigger context variables), but it's just that... a suggestion.



            Keeping updates of related objects in after triggers (or not in before triggers) has a few benefits:




            • Following this advice helps logically separate the work done on object X itself, and the work done on the records Y and Z that are related to X

            • If you run into an issue (null pointer exceptions, validation exceptions, etc...) in a before trigger (or more accurately, before the after trigger is run), and have related record update logic in an after trigger, then you potentially won't spend time doing more work that will just be rolled back (compared to if your related record update logic were in a before trigger)

            • Related to the above point, this "fail fast" mechanism (and not doing ultimately meaningless work) means that you have less chance of running out of one of the resources monitored by the governor limits (which could end up masking another error).


            Another reason to avoid updating related records in before triggers is that related records can't take advantage of the "free update" that's available in before triggers (when making a change to a record stored in trigger.new and/or trigger.newMap)



            Conclusion:



            You could put your related record update logic into a before trigger, but you should think long and hard about whether or not that's really a good idea.






            share|improve this answer
























            • Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

              – sfdcfox
              Mar 21 at 13:55











            • @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

              – Derek F
              Mar 21 at 14:11






            • 1





              Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

              – sfdcfox
              Mar 21 at 14:15














            4












            4








            4







            If I understand your question correctly, then you actually can take your related record update logic and put it in either a before or after trigger.



            Salesforce's suggestion is that before triggers should be used to update data on the records taking part in the trigger (the ones stored in trigger context variables), but it's just that... a suggestion.



            Keeping updates of related objects in after triggers (or not in before triggers) has a few benefits:




            • Following this advice helps logically separate the work done on object X itself, and the work done on the records Y and Z that are related to X

            • If you run into an issue (null pointer exceptions, validation exceptions, etc...) in a before trigger (or more accurately, before the after trigger is run), and have related record update logic in an after trigger, then you potentially won't spend time doing more work that will just be rolled back (compared to if your related record update logic were in a before trigger)

            • Related to the above point, this "fail fast" mechanism (and not doing ultimately meaningless work) means that you have less chance of running out of one of the resources monitored by the governor limits (which could end up masking another error).


            Another reason to avoid updating related records in before triggers is that related records can't take advantage of the "free update" that's available in before triggers (when making a change to a record stored in trigger.new and/or trigger.newMap)



            Conclusion:



            You could put your related record update logic into a before trigger, but you should think long and hard about whether or not that's really a good idea.






            share|improve this answer













            If I understand your question correctly, then you actually can take your related record update logic and put it in either a before or after trigger.



            Salesforce's suggestion is that before triggers should be used to update data on the records taking part in the trigger (the ones stored in trigger context variables), but it's just that... a suggestion.



            Keeping updates of related objects in after triggers (or not in before triggers) has a few benefits:




            • Following this advice helps logically separate the work done on object X itself, and the work done on the records Y and Z that are related to X

            • If you run into an issue (null pointer exceptions, validation exceptions, etc...) in a before trigger (or more accurately, before the after trigger is run), and have related record update logic in an after trigger, then you potentially won't spend time doing more work that will just be rolled back (compared to if your related record update logic were in a before trigger)

            • Related to the above point, this "fail fast" mechanism (and not doing ultimately meaningless work) means that you have less chance of running out of one of the resources monitored by the governor limits (which could end up masking another error).


            Another reason to avoid updating related records in before triggers is that related records can't take advantage of the "free update" that's available in before triggers (when making a change to a record stored in trigger.new and/or trigger.newMap)



            Conclusion:



            You could put your related record update logic into a before trigger, but you should think long and hard about whether or not that's really a good idea.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Mar 21 at 13:50









            Derek FDerek F

            20.7k52253




            20.7k52253













            • Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

              – sfdcfox
              Mar 21 at 13:55











            • @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

              – Derek F
              Mar 21 at 14:11






            • 1





              Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

              – sfdcfox
              Mar 21 at 14:15



















            • Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

              – sfdcfox
              Mar 21 at 13:55











            • @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

              – Derek F
              Mar 21 at 14:11






            • 1





              Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

              – sfdcfox
              Mar 21 at 14:15

















            Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

            – sfdcfox
            Mar 21 at 13:55





            Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

            – sfdcfox
            Mar 21 at 13:55













            @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

            – Derek F
            Mar 21 at 14:11





            @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

            – Derek F
            Mar 21 at 14:11




            1




            1





            Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

            – sfdcfox
            Mar 21 at 14:15





            Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

            – sfdcfox
            Mar 21 at 14:15













            3














            Using the after trigger event is strongly recommended, but not necessary, for updating related records, because before trigger events can modify the records in an unpredictable order. Waiting until the records have been committed to the database reduces this possibility. Note that there are some specific scenarios where it is even desirable to work with related records in a before trigger, such as if you want to create parent records if they are missing.



            As a simple example, consider these two "triggers" (pseudo-code) that deal with contacts:



            trigger CreateGuid on Contact (before insert) {
            ContactTriggerHelper.createGuidsForContacts(Trigger.new);
            }




            trigger UpdateGuidList on Contact (before insert) {
            ContactTriggerHelper.updateGuidOnAccounts(Trigger.new);
            }




            If CreateGuid runs first, the Account will show the correct values by the end of the transaction. However, if UpdateGuidList runs first, the values will still be null. We cannot strictly predict ahead of time which trigger will run first.



            However, if we move UpdateGuidList to an after insert event, we guarantee that the contacts will have the correct data before the update to the related records occur. This is generally desirable behavior.



            As an alternative to this problem, what if one trigger automatically assigns a value to the lookup field, and another updates the record? In that case, the wrong record could get updated, and it would be troublesome to even debug, because the order of operations are not guaranteed between trigger events that occur at the same time.





            Unless you know for sure that nobody will ever depend on the order of operations of the triggers, or that the order of execution does not matter, stick with the after trigger event for updating related records. It is much easier to use after trigger events all the time and not have to guess about possible side effects than it is to risk random or periodic logic failures because someone did not take your trigger into account when adding more logic elsewhere.






            share|improve this answer




























              3














              Using the after trigger event is strongly recommended, but not necessary, for updating related records, because before trigger events can modify the records in an unpredictable order. Waiting until the records have been committed to the database reduces this possibility. Note that there are some specific scenarios where it is even desirable to work with related records in a before trigger, such as if you want to create parent records if they are missing.



              As a simple example, consider these two "triggers" (pseudo-code) that deal with contacts:



              trigger CreateGuid on Contact (before insert) {
              ContactTriggerHelper.createGuidsForContacts(Trigger.new);
              }




              trigger UpdateGuidList on Contact (before insert) {
              ContactTriggerHelper.updateGuidOnAccounts(Trigger.new);
              }




              If CreateGuid runs first, the Account will show the correct values by the end of the transaction. However, if UpdateGuidList runs first, the values will still be null. We cannot strictly predict ahead of time which trigger will run first.



              However, if we move UpdateGuidList to an after insert event, we guarantee that the contacts will have the correct data before the update to the related records occur. This is generally desirable behavior.



              As an alternative to this problem, what if one trigger automatically assigns a value to the lookup field, and another updates the record? In that case, the wrong record could get updated, and it would be troublesome to even debug, because the order of operations are not guaranteed between trigger events that occur at the same time.





              Unless you know for sure that nobody will ever depend on the order of operations of the triggers, or that the order of execution does not matter, stick with the after trigger event for updating related records. It is much easier to use after trigger events all the time and not have to guess about possible side effects than it is to risk random or periodic logic failures because someone did not take your trigger into account when adding more logic elsewhere.






              share|improve this answer


























                3












                3








                3







                Using the after trigger event is strongly recommended, but not necessary, for updating related records, because before trigger events can modify the records in an unpredictable order. Waiting until the records have been committed to the database reduces this possibility. Note that there are some specific scenarios where it is even desirable to work with related records in a before trigger, such as if you want to create parent records if they are missing.



                As a simple example, consider these two "triggers" (pseudo-code) that deal with contacts:



                trigger CreateGuid on Contact (before insert) {
                ContactTriggerHelper.createGuidsForContacts(Trigger.new);
                }




                trigger UpdateGuidList on Contact (before insert) {
                ContactTriggerHelper.updateGuidOnAccounts(Trigger.new);
                }




                If CreateGuid runs first, the Account will show the correct values by the end of the transaction. However, if UpdateGuidList runs first, the values will still be null. We cannot strictly predict ahead of time which trigger will run first.



                However, if we move UpdateGuidList to an after insert event, we guarantee that the contacts will have the correct data before the update to the related records occur. This is generally desirable behavior.



                As an alternative to this problem, what if one trigger automatically assigns a value to the lookup field, and another updates the record? In that case, the wrong record could get updated, and it would be troublesome to even debug, because the order of operations are not guaranteed between trigger events that occur at the same time.





                Unless you know for sure that nobody will ever depend on the order of operations of the triggers, or that the order of execution does not matter, stick with the after trigger event for updating related records. It is much easier to use after trigger events all the time and not have to guess about possible side effects than it is to risk random or periodic logic failures because someone did not take your trigger into account when adding more logic elsewhere.






                share|improve this answer













                Using the after trigger event is strongly recommended, but not necessary, for updating related records, because before trigger events can modify the records in an unpredictable order. Waiting until the records have been committed to the database reduces this possibility. Note that there are some specific scenarios where it is even desirable to work with related records in a before trigger, such as if you want to create parent records if they are missing.



                As a simple example, consider these two "triggers" (pseudo-code) that deal with contacts:



                trigger CreateGuid on Contact (before insert) {
                ContactTriggerHelper.createGuidsForContacts(Trigger.new);
                }




                trigger UpdateGuidList on Contact (before insert) {
                ContactTriggerHelper.updateGuidOnAccounts(Trigger.new);
                }




                If CreateGuid runs first, the Account will show the correct values by the end of the transaction. However, if UpdateGuidList runs first, the values will still be null. We cannot strictly predict ahead of time which trigger will run first.



                However, if we move UpdateGuidList to an after insert event, we guarantee that the contacts will have the correct data before the update to the related records occur. This is generally desirable behavior.



                As an alternative to this problem, what if one trigger automatically assigns a value to the lookup field, and another updates the record? In that case, the wrong record could get updated, and it would be troublesome to even debug, because the order of operations are not guaranteed between trigger events that occur at the same time.





                Unless you know for sure that nobody will ever depend on the order of operations of the triggers, or that the order of execution does not matter, stick with the after trigger event for updating related records. It is much easier to use after trigger events all the time and not have to guess about possible side effects than it is to risk random or periodic logic failures because someone did not take your trigger into account when adding more logic elsewhere.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Mar 21 at 13:48









                sfdcfoxsfdcfox

                261k12207452




                261k12207452






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Salesforce Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f254752%2fwhy-do-we-need-to-update-related-records-in-an-after-trigger-but-not-before%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Plaza Victoria

                    In PowerPoint, is there a keyboard shortcut for bulleted / numbered list?

                    How to put 3 figures in Latex with 2 figures side by side and 1 below these side by side images but in...