On Wed, Jul 22, 2015 at 2:55 PM, Uvindra Dias Jayasinha <[email protected]> wrote:
> Let me summarise, > > If the requirement is to only transfer the subscriptions of the API > version we are copying from, then we need to store the parent API version > in the rxt or the DB as has been already suggested. > I believe this is the correct requirement and the solution. Note: We should only copy the active subscriptions. Not the ones on hold due to workflow approvals. > > But if the requirement is to transfer all subscriptions of an existing > APIs versions to the new API we can simply do a duplicate check before > trying to insert subscription data which is a simple fix. > > So which is the correct functionality? > I think for 1.9.1, we should just live with the duplicate check since we're unable to do any rxt changes. But make a note in 1.10 so we do not iterate through all versions and copy subscriptions of all versions. > > On 22 July 2015 at 14:36, Uvindra Dias Jayasinha <[email protected]> wrote: > >> @Sajith, we already have those options you have mentioned in API Manager, >> if we are publishing a new version of an API either we can choose to make >> the users of the API to re-subscribe or we can automatically transfer over >> the subscriptions from the previous version. >> >> On 22 July 2015 at 14:25, Sajith Ariyarathna <[email protected]> wrote: >> >>> Hi Uvindra, >>> >>> As pointed out by RuwanA, AppM had a similar problem when creating a new >>> version of a web app based on an existing version. In AppM, when >>> 'Publish'ing version *2.0.0* of web app *Foo* (which was created from >>> *Foo* version *1.0.0*), version *1.0.0* is 'Un-publish'ed (because only >>> one version of a web app is shown to end-users in the store) and >>> subscriptions >>> from version *1.0.0* are moved to version *2.0.0*. This is not exactly >>> your situation in APIM, but you can see that subscriptions are moved to the >>> new version when it is 'Publish'ed. >>> >>> Suggestion: you should give the option to the Publisher to decide >>> whether to copy or move subscriptions to the new version. You can give 03 >>> options, "Copy Subscriptions to v2.0.0", "Move Subscriptions to v2.0.0" and >>> "Do Nothing". I believe it will improve the user experience for API >>> Publisher. >>> >>> As suggested by RuwanA, keeping the 'parentID' in the asset or in the >>> DB will also help to maintain a version hierarchy and in future releases >>> you can use that data to do API grouping or to show a versioning tree. >>> >>> Thanks and Regards. >>> >>> >>> On Wed, Jul 22, 2015 at 1:00 PM, Ruwan Abeykoon <[email protected]> wrote: >>> >>>> Hi Uvindra, >>>> What if we keep the "parent" apiID in the asset itself, rather than in >>>> new DB column. (by adding the field to api.rxt) >>>> >>>> Cheers, >>>> Ruwan >>>> >>>> On Wed, Jul 22, 2015 at 12:44 PM, Uvindra Dias Jayasinha < >>>> [email protected]> wrote: >>>> >>>>> The correct way I can think of solving this is to store the apiID of >>>>> the version that is being copied from in the newly created api object so >>>>> that we can make the association later on when we are publishing the new >>>>> api version. >>>>> >>>>> This means we will need to add a new column to the AM_API table to >>>>> store this, hence Im trying to see if there is an alternative. >>>>> >>>>> >>>>> >>>>> On 22 July 2015 at 12:38, Uvindra Dias Jayasinha <[email protected]> >>>>> wrote: >>>>> >>>>>> Thanks for the suggestion Ruwan, but we are not on ES yet and wont be >>>>>> for sometime so we wont be able to exploit that feature. >>>>>> >>>>>> On 22 July 2015 at 12:32, Ruwan Abeykoon <[email protected]> wrote: >>>>>> >>>>>>> Hi Uvindra, >>>>>>> We are having same issue and being solved in AppM 1.1.0. We were >>>>>>> informed that ES 2.0 has grouping capability. So we may be exploit that >>>>>>> to >>>>>>> correlate versions. We plan to back-port some ES 2.0 functions to ES 1 >>>>>>> branch to get this done. >>>>>>> >>>>>>> SajithAR working on this. >>>>>>> >>>>>>> Cheers, >>>>>>> Ruwan >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 22, 2015 at 12:21 PM, Uvindra Dias Jayasinha < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> This applies to API Manager 1.9.0, but this is true for previous >>>>>>>> versions as well. When trying to fix the following ticket[1] I came >>>>>>>> across >>>>>>>> this scenario, >>>>>>>> >>>>>>>> 1. API named *"foo"* with versions *"1.0.0"* and *"2.0.0"* has >>>>>>>> existing subscriptions. >>>>>>>> 2. Create a new version of the same API *"3.0.0"* from *"2.0.0"* >>>>>>>> . >>>>>>>> 3. Publish API *"foo:3.0.0"* with the "Require >>>>>>>> Re-Subscription" option disabled. >>>>>>>> 4. What should happen is that the subscriptions of *"foo:2.0.0"* >>>>>>>> should be applied to *"foo:3.0.0" *automatically >>>>>>>> >>>>>>>> >>>>>>>> The problem is step *2 *and *3* above are separate so there is >>>>>>>> currently no association between *"foo:2.0.0"* and *"foo:3.0.0"*. >>>>>>>> >>>>>>>> So how do we determine which API version *"foo:3.0.0"* was created >>>>>>>> from so that we can transfer that APIs subscriptions at the time of >>>>>>>> publishing? >>>>>>>> >>>>>>>> Is there a way to do this without adding a new attribute to the >>>>>>>> newly created API to indicate whihc version it was copied from? >>>>>>>> >>>>>>>> [1] https://wso2.org/jira/browse/APIMANAGER-3971 >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> Uvindra >>>>>>>> >>>>>>>> Mobile: 777733962 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> [email protected] >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Ruwan Abeykoon* >>>>>>> *Architect,* >>>>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>>>>>> *lean.enterprise.middleware.* >>>>>>> >>>>>>> email: [email protected] >>>>>>> phone:(+94) 777739736 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Uvindra >>>>>> >>>>>> Mobile: 777733962 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Uvindra >>>>> >>>>> Mobile: 777733962 >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Ruwan Abeykoon* >>>> *Architect,* >>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>>> *lean.enterprise.middleware.* >>>> >>>> email: [email protected] >>>> phone:(+94) 777739736 >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Sajith Ariyarathna >>> Software Engineer; WSO2, Inc.; http://wso2.com/ >>> mobile: +94 77 6602284, +94 71 3951048 >>> >> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> > > > > -- > Regards, > Uvindra > > Mobile: 777733962 > -- Nuwan Dias Technical Lead - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
