-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve UX for complex/nested objects #186
Comments
This question came up again in #irc. We should definitely bump this for 1.6 |
I agree with @al3xandru. |
So here's a proposal for a simple syntax we can add that isn't terribly hard and I think covers a lot of the issues people were running in to. obj.set('attr1', 'attr2', 'attr3', value) The imperative version of this would be: obj['attr1']['attr2']['attr3'] = value
return obj People would probably prefer the version with the imperative look but I think we're going to have trouble fitting that nicely in to our query language. There's a lot of questions that come up there. |
I was planning to suggest the 2nd solution to which I arrived after starting with the 1st. I was also thinking that this might be complicated implementation wise, but while I think I could get used to the 1st, I find it a bit more less legible. How about: obj.set({'attr1': {'attr2': {'attr3': value}}}) It's longer, but the structure/depth is more obvious. update: isn't the above already possible with |
@al3xandru I believe that's the semantics of merge. I'm not sure if it's recursive right now but I think it should be. |
What @al3xandru proposed is close to merge. I like the first syntax of |
|
So I just checked merge isn't recursive right now which means it does overwrite the values of the sub attributes as @neumino said. Also @al3xandru I have no idea what you mean by this: "We could use the same approach/syntax for set (and be consistent)" What exactly is going to be the same here? |
Not sure I'm using the right words to describe what I mean, but having doc.merge(
{ 'attr1': {
'attr2': {
'attr3': value }
}
}) overwrites doc.set(
{ 'attr1': {
'attr2': {
'attr3': value }
}
}) sets |
So I'm still a bit confused. It seems like you've basically just flipped the meanings that @neumino and I were talking about in that you've made |
I'm not sure I understand what I've flipped or not :-). I was just trying to come up with a proposal for
|
I don't like recursive merge. With a recursive merge, the result of this query:
Will not always be { 'key' : value }. It could be { 'key' : {'foor':bar}.merge(value) }. That is very surprising. |
I really liked @jdoliner's original proposal (outlined on ggroups) -- support map over objects, and then implement various forms of |
I think there's actually a reasonable argument for defaulting to a deep merge. That's what I think I'd usually want. |
@coffeemug can you paste that proposal here? @mlucy deep merge is very useful but I would never expect it to be the default. |
Here's the original complaint: Are there any examples of manipulating documents at a deeper level than the first level of keys? The experience I've had so far attempting to do mutations has been quite painful in comparison to, say, MongoDB. As an example, say I have a document:
If I want to set If I want to change (Is this kind of update even an advisable use case for RethinkDB? AFAIK, this is considered a normal use case for MongoDB and is easily supported1 by using syntax like |
Here's @jdoliner's proposal (which doesn't deal with arrays and might have a nicer user-facing API but is a good base for this): I think that the basic primitive operation we want here is a generic Merge which would have the following semantics
With this we could then implement a specific type of Merge which called itself on sub objects (call it RMerge) so in your example of updating
Notice that our current merge can also be implemented in terms of this with the function (f a b -> b). And we'd probably want to add some sugar so you didn't need to specify the common cases in update. Also as a note all of this is easily implemented in terms of map over objects which we've talked about before as well. |
Bumping since someone asked this again on IRC. Relevant gist: https://gist.github.com/neumino/5607840 |
As pointed out by @saurik here https://groups.google.com/forum/?fromgroups=#!topic/rethinkdb/sSB-rtXQPsk, the user experience of accessing nested objects isn't great. Consider the following cases:
Additionally, while not discussed in the post, there is a question of querying based on sub-sub elements or groups of sub-sub-elements on different levels.
@jdoliner proposed map on objects, a general purpose merge operation based on the object map, a set of sugar operations based on that, and ability to pass a custom merge function to update. All of these are great and necessary. We'll also need to think through potential defaults for update, array modification ops, querying complex objects, and possibly more sugar functions for dealing with complex hierarchies (such as
flatten
).The text was updated successfully, but these errors were encountered: