Hi Michal, > I think it would be great to have this unified across all driver, before > we start advertising the new Library code.
Definitely. > driver.instance(:id => 'unknown') => nil > driver.instances(:id => 'unknown') => [] > > I think this behavior is more easy to understand that capturing different > kinds of exceptions. What do you think? How does this relate to the RESTful API? api/instances/non-existing-instance-id I would expect a 404 from a REST API. Is there code in DC that will convert the nil to a 404 error page? If so, then agreed. Regards, Dies Koper > -----Original Message----- > From: Michal Fojtik [mailto:[email protected]] > Sent: Thursday, 26 July 2012 6:26 PM > To: [email protected] > Subject: Re: [PATCH core 1/7] RHEV-M: Fixed bug that cause instance not > pick up image_id > > Hi Dies, > > While I working on driver unit tests, I discovered that different drivers > use different ways how to return data. For example in EC2, when you query > for 'non-existing' resource (like instance), an Exception is being raised > whereas in Mock driver, the method just return empty array or 'nil'. > > I think it would be great to have this unified across all driver, before > we start advertising the new Library code. > > So I took the 'Mock' driver as an example, mean that: > > driver.instance(:id => 'unknown') => nil > driver.instances(:id => 'unknown') => [] > > I think this behavior is more easy to understand that capturing different > kinds of exceptions. What do you think? > > -- Michal > > > --- > Michal Fojtik, Sr. Soft. Engineer > Deltacloud API / CloudForms > [email protected] > > On Jul 26, 2012, at 3:25 AM, David Lutterkort wrote: > > > On Thu, 2012-07-26 at 09:36 +1000, Koper, Dies wrote: > >> FGCP returns an error in this case as I wasn't aware of this convention. > >> Where do I find such conventions? Surely not only in the commit > >> messages? > > > > I believe Michal changed this recently - but yes, the docs for the > > driver API are lacking. It would be great if an enterprising soul went > > through the existing drivers and looked for differences in how they > > handle this stuff and/or write that down. > > > > David > > > > >
