rethinkdb 1.7
christopherhesse opened this issue · 11 comments
Update to rethinkdb 1.7
Also maybe fix up some struct behavior.
Breaking changes
getattr was renamed to get_field. (The original name dates back almost to the start of RQL, before our current naming conventions were in place.)
New terms
json — takes a JSON string and parses it into a DATUM on the server. Very useful for sending large objects to the server from languages with slow protobuf libraries (in our experience, neraly all of them).
Enhancements to old terms
Atomic set and get! insert, delete, update, and replace now take an optional argument "return_vals“. ”return_vals" is only valid for single-row operations. When set to true, it returns the old and new value of the row being operated on. For example, table.get(0).update{|row| {:x => row[:x].add(1)}}will return as part of the summary object the old value of the row, allowing users to see what x was before and after it was incremented.
get_field (formerly getattr) is now polymorphic on both objects and streams. stream.get_field('f')is the same as stream.concat_map{|x| r.branch(x.has_fields('f'), [x.get_field('f')], []).
pluck now takes a more advanced pattern matching syntax in addition to simple field names. See https://gist.github.com/coffeemug/5894446. We plan to extend this syntax to other commands in 1.8.
" I forgot about get_all; it now takes any number of arguments in addition to its index optarg. Old drivers referring to getattr will continue to function until you switch to the new .proto file, at which point they will have to refer to get_field."
use the json thing internally instead of datum
sql module uses NullType stuff for structs, would this work with the json module?: http://golang.org/pkg/database/sql/
on the server a field can be undefined, null, or a value, in a struct it can be only a value.
does json:omitempty solve this problem well enough? may not handle nulls particularly well
Very exciting!
Also add a json literal
json thing can't replace datums everywhere: rethinkdb/rethinkdb#1139 so hold off on that for now
Waiting!