Hi all, When I look at the amount code code changes that it required to get the resource and collection rename working correctly is not small . And doing critical changes at this point (I mean closer to a release) is not a good idea , therefore I am not going to implement collection rename , and I will delete the code that I have written to handle the collection rename as well. We can keep the resource rename since we can get that working correctly , so I will keep the resource rename code , in addition to that I updated the wiki and add the rename functionality there.
Thank you, Deepal > hmm , when I am doing the resource rename implementation I faced a > problem : ) , actually this problem came to picture when I want to > implement directory rename. I go the resource rename working as well as > restore working fine. Say we have two resource as follows > /abc/def/r1 > /abc/def/r2 > > And let's say we rename /abc/def into /def/abe , then all the resource > in the /abc/def has to copy into /def/abe in this case (r1 and r2) , I > also got that working by updating the dependency table. But I did not > update the child node paths in the artifact table. So when I get the > child nodes of the /def/abe I got r1 and r2 but with old names. The > problem here is I can change the path of the resource in the artifact > table , if I do so then if I do the restore in /abc/def then will have > some problem. This brought me to a two approach to solve the problem > 1- Store the path in version table > 2 - Rather than storing full path of the resource table , we can > store only the resource name , i.e say the resource path is /abc/xyz/r1 > then we just store the name as r1 , and when some one ask for that > resource , using version table and dependency table we identify the > resource and return that. > > I am bit stuck here , so I would like to have a meeting at least with SL > people and come to a conclusion before doing any changes. > -Deepal > >> +1 .. also, I'd *really* like a GET on the old path to result in a 304 >> Moved Permanently HTTP response .. >> >> Sanjiva. >> >> Deepal Jayasinghe wrote: >> >>>> +1 from me too, although we need to think carefully about how this new >>>> functionality gets exposed via the APP interface. In particular, I >>>> think we need to support a rename/move as a *single* remote operation, >>>> triggered by a POST somewhere.... >>>> >>> Yes that what is I am planing to. >>> >>> -Deepal >>> >>>> --Glen >>>> >>>> Sanjiva Weerawarana wrote: >>>> >>>>> +1. >>>>> >>>>> Sanjiva. >>>>> >>>>> Deepal Jayasinghe wrote: >>>>> >>>>>> Hi all , >>>>>> >>>>>> I have implement the resource rename in my local machine , but >>>>>> that to >>>>>> be useful I think we need to change Registry API to have the >>>>>> renameResource or moveResource method . Is that ok if I go ahead and >>>>>> add >>>>>> that and commit the code ? >>>>>> >>>>>> -Deepal >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Registry-dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev >>>>>> >>>>>> >>>> _______________________________________________ >>>> Registry-dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev >>>> >>>> >>>> >>> _______________________________________________ >>> Registry-dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev >>> >>> > > > > _______________________________________________ > Registry-dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/registry-dev > > > _______________________________________________ Registry-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
