API method to get a list of all [depot] filenames in a diff

 






 

 


  Review Request #1199
  —
  Created Nov. 8, 2009 and discarded

 


















 

  

   Information

  





 
 

  pv
 









 
 

  Review Board
 









 
 

  master
 









 
 

  
 









 
 

  
 






 




 

  

   Reviewers

  





 
 

  reviewboard
 









 
 

  mak
 






 








 





  


 
 

  
Review 1013 (http://reviews.reviewboard.org/r/1013/) is useful to me, but I am trying to get a list of all of [latest] filenames in a review request.
This change extends Mak's (1013) change to allow me to do that.

This solution requires two JSON calls for me to get a list of filenames.
1) http://server/reviewrequests/%d/diff/
2) http://server/diff/%d/filenames/

In all honesty, I don't actually like needing to make two JSON calls when I could implement what I need in one JSON call.

So, Option #2, I would much prefer the a single request such as:
http://server/reviewrequests/%d/filenames/
(This always gets the filenames from the latest diff revision)

Option #3, another alternative, would be to get a list of filenames directly from a reviewrequest's diff revisions:
http://server/reviewrequests/%d/diff/latest/filenames/ 
http://server/reviewrequests/%d/diff/%d/filenames/ 


Option #3 is kindof slick, but I prefer Option #2, since this doesn't obligate me to complicate the API with a "latest" revision alias.



Finally, would Mak be OK w/ me changing his API from "/diff/" to "/diffs/"?

 








  


 
 

  
Change is still open to debate, so no test(s) added yet.

 







 









 





  








 









 






  

 








 














 



 

  

   





 PV





   

   

  

 



 

  


   

   

    
 Review request changed

    
   


  

  

  











 



  

   
Diff:

   
    
 Revision 2 (+23)
Show changes
 
    reviewboard/webapi/json.py 
    reviewboard/webapi/urls.py 
 

   		
  



 










  

 
















 





 

  

   




chipx86




   

   





  

 



 

  


   

   

    
 
chipx86


    
   


  

  

  



    




  1. 
 
    
  
    
   
    I'm unsure of how this maps to option #2. You still need to know the diffset ID. You just don't need the review request ID. However, we can't accept a change that puts a /api/json/diffs/... tree. Anything diff-related should be in reviewrequests/<id>/diff/ somewhere.

What I'd be okay with is adding reviewrequests/<id>/diff/<diffsetid>/ and reviewrequests/<id>/diff/latest/. It should return the filediffs inside of it, though, not just filenames.
    
  
    
 
    

 
    
  


    
 
    
 
      

  


    1. 
 
 
      
 
      
  
 
      
 
      
  
      The change was mostly just a proposal/RFC and only implemented option #1.
#2 would have been a nice lightweight solution just for my needs.
Sounds like you'd be OK w/ #3, which I will code up Monday. The solution will return the whole filediffs, not just the names.
(I am OK w/ parsing the filediffs on the caller and extracting the depot_filenames; simple list comprehension).

Understood about not wanting a root "diffs" api.
That said, why not alias all diffs in the API w/ a '[s]?', as in:
  r'reviewrequests/(?P<review_request_id>[0-9]+)/diff[s]?/(?P<diff_revision>[0-9]+)/'
'.../diffs/42/...' makes more logical sense than '.../diff/42/...'

      
 
      

      2. 



    2. 
 
 
      
 
      
  
 
      
 
      
  
      Maybe at some point. There's actually a lot I want to do with the API, some of which may be backwards-incompatible, but I'm trying to limit things right now. Might explore this for 1.2.
      
 
      

      3. 



    3. 
 
 
      
 
      
  
 
      
 
      
  
      Sorry, I didn't see this earlier. But I don't use the Account "mak" anymore (Christian: Can you please change the user under "People"?).
To the request: #2 looks good to me. Even though I probably won't use it (I just extract the filenames from the diff).
      
 
      

      4. 


 
    


    

 
    

    2. 















  2. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 
















 





 

  

   




chipx86




   

   





  

 



 

  


   

   

    
 
chipx86


    
   


  

  

  



    




  1. 
 
    
  
    
   
    The new API in 1.5 beta 2 has all this information now.
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    2. 















  2. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 









     

    

   

  

  

   
   Loading...