[MDEV-13323] json_set returns NULL instead of object Created: 2017-07-14  Updated: 2017-09-11  Resolved: 2017-07-14

Status: Closed
Project: MariaDB Server
Component/s: JSON
Fix Version/s: N/A

Type: Task Priority: Major
Reporter: Ian Gilfillan Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates MDEV-13324 JSON_SET returns NULL instead of object Closed

 Description   

In MySQL 5.7:

SELECT JSON_SET('{}', '$.age', 87); 
+-----------------------------+
| JSON_SET('{}', '$.age', 87) |
+-----------------------------+
| {"age": 87}                 |
+-----------------------------+

In MariaDB 10.2:

SELECT JSON_SET('{}', '$.age', 87); 
+-----------------------------+
| JSON_SET('{}', '$.age', 87) |
+-----------------------------+
| NULL                        |
+-----------------------------+



 Comments   
Comment by Elena Stepanova [ 2017-07-14 ]

Duplicate of MDEV-13324

Comment by Steven WdV [ 2017-09-11 ]

is duplicated by should be duplicates

Comment by Elena Stepanova [ 2017-09-11 ]

StevenWdV,
Can you give any reference to what makes you be sure about it?
We've discussed this dilemma several times, and there is still no 100% certainty, so I'm very interested to see a definite proof of one way or another.

Our current interpretation which seems to make most sense is that "X duplicates Y" stands for "X makes Y a duplicate", while "X is duplicated by Y" stands for "X is made a duplicate by Y", or, in other words, "Y makes X a duplicate". Thus, the "is duplicated by" is set on the item which is closed as a duplicate, while "duplicates" is set on the original.

I won't change it back because it doesn't matter much anyway.

Comment by Steven WdV [ 2017-09-11 ]

elenst This is how Mojang uses it, see for example https://bugs.mojang.com/browse/MC-69351. Also see https://community.atlassian.com/t5/Jira-questions/duplicates-vs-duplicated-by/qaq-p/285515 which confirms this is the intended way.

EDIT: To be honest, I don't think X makes Y a duplicate makes much sense, since X was reported first and therefore X can not 'make' Y a duplicate, if you know what I mean. But that's just my opinion I guess.

By the way: I think this is how it is done on jira.mariadb.org as well; see for example ODBC-96 and ODBC-89.

Comment by Elena Stepanova [ 2017-09-11 ]

StevenWdV,
Thank you. The second link indeed answers this question quite clearly (assuming the answer comes from the person who knows rather than speculates).

For the ODBC example, yes, as I said, we are still not very clear on this subject, so we tend to use them interchangeably, just like I'm sure the rest of the JIRA universe.

In any case, names of these links are supplementary, the real relationship is always established by the resolution on the report (Duplicate on one vs anything else on another). Links would only make a difference if you had three reports, X a duplicate of Y and Y a duplicate of Z, then links on Y would matter; but such relationship would be wrong anyway.

In regard to this:

I don't think X makes Y a duplicate makes much sense, since X was reported first and therefore X can not 'make' Y a duplicate, if you know what I mean

I'm not quite sure what you mean. If you are referring to my generalization (or the one in the question/answer, which coincidentally also uses X/Y notion), it's just notion, it doesn't imply that X is necessarily older than Y. Call them 'foo' and 'bar', or anything that doesn't establish an obvious order.

But if you were speaking in general, that an older item cannot be a duplicate of a newer one, I totally agree with you, I think it's a rather nasty habit in many, many bugtrackers. In MDEV project we are trying to establish the rule that an older item cannot be a duplicate of a newer item, with rare exceptions, at least whenever it concerns bugs reported by users (we cut corners sometimes when it comes to our own reports). It's just that in this particular case it was a pure technicality, as you can see, these items are identical and created within minutes from each other, due to a JIRA glitch or wrongly pressed button.

Generated at Thu Feb 08 08:04:41 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.