Ticket has been updated with the requirement, please add 1.10 release to API Manager JIRA to set the fix version so that this can be prioritised.
On 22 July 2015 at 15:10, Nuwan Dias <nuw...@wso2.com> wrote: > > > On Wed, Jul 22, 2015 at 2:55 PM, Uvindra Dias Jayasinha <uvin...@wso2.com> > 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 <uvin...@wso2.com> >> 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 <sajit...@wso2.com> 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 <ruw...@wso2.com> >>>> 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 < >>>>> uvin...@wso2.com> 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 <uvin...@wso2.com> >>>>>> 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 <ruw...@wso2.com> 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 < >>>>>>>> uvin...@wso2.com> 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 >>>>>>>>> Dev@wso2.org >>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Ruwan Abeykoon* >>>>>>>> *Architect,* >>>>>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>>>>>>> *lean.enterprise.middleware.* >>>>>>>> >>>>>>>> email: ruw...@wso2.com >>>>>>>> phone:(+94) 777739736 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Uvindra >>>>>>> >>>>>>> Mobile: 777733962 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Uvindra >>>>>> >>>>>> Mobile: 777733962 >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> Dev@wso2.org >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Ruwan Abeykoon* >>>>> *Architect,* >>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>>>> *lean.enterprise.middleware.* >>>>> >>>>> email: ruw...@wso2.com >>>>> phone:(+94) 777739736 >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> Dev@wso2.org >>>>> 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 : nuw...@wso2.com > Phone : +94 777 775 729 > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
