[SERVER-28078] Database entry internal query redirecting by new type of referencing Created: 23/Feb/17 Updated: 24/Jun/17 Resolved: 24/Jun/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Tobias Weber [X] | Assignee: | Asya Kamsky |
| Resolution: | Won't Fix | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Participants: |
| Description |
| Comments |
| Comment by Asya Kamsky [ 24/Jun/17 ] |
|
I think this may already be achievable by views, as I said above, which allow creating fields which actually contain contents of other fields in the document. Just to make it clear, we decided to close this ticket rather than leaving it in backlog for indefinite future, because we don't think this is something we would consider implementing in the near future. Asya |
| Comment by Tobias Weber [X] [ 16/May/17 ] |
|
I imagine the new reference type as a special kind of string field. It will be created during encoding by self-implemented codecs, at the place where a document would have to be that would contain duplicate data. The reference will then receive an absolute string node path from the uppermost root document to the first and only persisted occurrence of the duplicate data. The reference will just remain there silently as a hint until a query comes along with a path that touches the reference. When that happens, the path of of the query will be changed by the reference's string content accordingly. So it definetely IS a new type, the only thing using it will be queries tough. That might the part I meant when I said "Or am I now missing your point?"... to me it sounded like you think I would want a new type that offers ways of nesting documents into each other when I am encoding. I just want to leave a hint for queries on how I have nested with the possibilites that are already there. |
| Comment by Asya Kamsky [ 15/May/17 ] |
|
My summary was the discussion among the query team and our conclusion.
I'm afraid I don't understand what that means, if it's not a new type that the server would have to support. |
| Comment by Tobias Weber [X] [ 15/May/17 ] |
|
Hi, thanks for the answer! I got to admit, my description was kind of long, so it was quite easy to miss my point. My request is NOT about making this new reference type so the mongo driver will provide a new way of getting around storing duplicate data - as you mentioned, there are multiple other ways already available to do that. What I want the references for is just as hints for the driver when it is evaluating queries! I need this as a way to redirect the query evaluation in-document to the place where the single instance of the duplicated data has been stored. So, as anonymous.user mentioned, this might indeed be a thing for the query team - I don't know which part of your system has to offer the functionality for this. Or am I now missing your point? Regards, Tobias |
| Comment by Asya Kamsky [ 15/May/17 ] |
|
Thank you for the request. After extensive internal discussion, we decided that implementation of this type of referencing does not belong within the server. It's possible you can achieve the effect of avoiding storing the same large field multiple times in the server document via read-only views - perhaps the framework you are building could leverage that feature somehow (Persist the structure storing the subdocument only once and resolve it via view definition that uses contents of that field via "$addFields" stage of aggregation). If it's more appropriate to store these large fields in their own document, you can leverage the DBRef convention, which our drivers already have some limited support for resolving. Warm regards, |
| Comment by Kelsey Schubert [ 23/Feb/17 ] |
|
Hi SenorDumpfbacke, Thanks for the feature request. I'm marking this ticket to be considered by the Query Team. Please continue to watch for updates. Kind regards, |