Should .pluck error behavior be like .without's?

[srh]

According to IRC user woogley, pluck(x, y, z) will error on rows lacking one of such keys x, y, or z. However, without(x, y, z) will not error if a row lacks such a key. In general it can be useful to trim down JSON documents to save on network traffic if you're only going to look at a subset of fields, even if some are lacking. Is erroring on rows that lack such fields the behavior we want?

[jdoliner]

I'd say without should error here.

My feeling is that we should error by default and offer people a way to have it not error if it's not found. Maybe we'd also want a way to have a default value for the plucks. I prefer this because compensating for missing parameters winds up being a big pain since it comes up in so many places and I don't think it's good to make people learn different rules for each case. Better to just consistently error if a parameter is missing and give people ways to have default values.

[codingcampbell]

Hi - I am woogley from IRC. To quickly illustrate my point:

r.db('test').tableCreate('shows').run()
r.db('test').table('shows').insert([ { name: 'Star Trek' }, { name: 'Breaking Bad', rating: 5 } ]).run()

Now, a vanilla run() will return:

[{"name":"Star Trek","id":"960e0533-4aa7-4c27-ae63-557f7dee92ca"},{"name":"Breaking Bad","rating":5,"id":"9d9690d5-e7bc-42e6-bab6-2e73c6c90422"}]

(The Star Trek entry simply lacks the rating key)

However, if you pluck:

r.db('test').table('shows').pluck('name', 'rating').run()

It throws this error:

Runtime Error: Attempting to pick missing attribute rating from data:

So I would say the inconsistency has less to do with without() and more to do with a vanilla run() on the table.

I would expect the pluck() to behave the same as a normal run() and let my application code deal with the missing key.

[coffeemug]

I think the behavior is correct as is. The server always behaves consistently -- if the query tries to evaluate an attribute and the attribute doesn't exist, it throws an error. If the query doesn't need to evaluate the attribute, the server proceeds as planned. In case of without, the value of the attribute isn't evaluated, so the error isn't thrown. Similarly, in case of run, the server evaluates the row, not the attribute, so everything works as expected as well.

As far as making dealing with these errors easier on the user, I agree with @jdoliner -- we'll address it via #27.

[jdoliner]

So the way to do this right now is as follows:

r.db('test').table('shows').map(lambda x: r.merge({"rating" : null}, x).pluck('name', 'rating').run()

Not pretty but it will let you run the query and have nulls filled in for the other values. Having defaults is in essence sugar for this command.

[coffeemug]

Added an issue to make it more pleasant, see #45.