[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: |
|
||||||||
| Description |
|
In MySQL 5.7:
In MariaDB 10.2:
|
| Comments |
| Comment by Elena Stepanova [ 2017-07-14 ] |
|
Duplicate of |
| Comment by Steven WdV [ 2017-09-11 ] |
|
is duplicated by should be duplicates |
| Comment by Elena Stepanova [ 2017-09-11 ] |
|
StevenWdV, 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 |
| Comment by Elena Stepanova [ 2017-09-11 ] |
|
StevenWdV, 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'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. |