fetch_type return value on notfound seems suboptimal

[macintux]

I suspect this may be a holdover from pre-bucket-type days. Currently, if an object isn't found, the return value is {error, {notfound, <type>}}, whereas for normal K/V operations it's {error, notfound}.

Since fetch_type doesn't take a type for each request, and since each bucket type can only work with one data type, returning the type as part of the error code seems unnecessary (and means client code needs to watch for two different patterns).

[seancribbs]

On the other hand, this would require the developer to fetch bucket properties, or know ahead of time and supply the expected type to modify_type. This was more about preventing unintentional errors and enabling the modify_type use-case. Honestly, if you're using datatypes this seems a minor inconvenience to match a slightly different pattern, given you're not working with riak objects anymore. Yes it's inconsistent, but it's a different API.

Would like more opinions on this.

[macintux]

If it has value, I'm definitely not strongly opposed to it, just wanted to make sure there was a reason for the behavior.

[macintux]

Closing as etoolittleroi