Chetan, from an operational point of view I have some fear that we will confuse the user by making the transaction id visible as a second id besides the activation id. Some will certainly use it to fetch activation records and fail, which will lead to questions. Any thoughts from your side ?
Regards, Martin > On 20. Aug 2019, at 12:32, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote: > > I created a separate thread to discuss how to store such metadata related > to activation. > > Current open PR #4586 only enables exposing the transactionId to env. It > does not make any attempt to store the transactionId currently. Once we > decide how such data should be stored then I can open PR for the same > > Chetan Mehrotra > > > On Mon, Aug 19, 2019 at 8:47 AM Rodric Rabbah <rod...@gmail.com> wrote: > >> Yes indeed. Your pr already open I think is fine as is. >> >> -r >> >> On Aug 19, 2019, at 11:36 AM, Chetan Mehrotra <chetan.mehro...@gmail.com> >> wrote: >> >>>> That’s true. Time for api/v2... >>> >>> This is now becoming a rabbit hole! What option should we use without >> going >>> for v2? >>> >>> 1. Introduce a new "meta" sub document >>> 2. OR Change annotations to flat map while storing but transform that to >>> array based structure while returning to client >>> >>> Chetan Mehrotra >>> >>> >>>> On Mon, Aug 19, 2019 at 7:15 AM Rodric Rabbah <rod...@gmail.com> wrote: >>>> >>>> >>>>> However changing them now would cause compatibility >>>>> issue with various tooling out there which may be interpreting the >>>>> annotation per current design >>>> >>>> That’s true. Time for api/v2... 😅 >>
