[SERVER-30547] $dateFromParts should accept an object from another expression Created: 08/Aug/17 Updated: 06/Dec/22 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | features we're not sure of |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Asya Kamsky | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query Optimization
|
||||||||
| Participants: | |||||||||
| Description |
|
Currently $dateFromParts only accepts explicit objects with required fields. It should be able to accept an expression as long as expression evaluates to an object with the required fields. This way a date can round trip through $dateToParts and $dateFromParts and end up as the same value (which would have caught
|
| Comments |
| Comment by David Storch [ 01/Feb/18 ] |
|
nicholas.zolnierz, no, I don't think we should pursue this now. It has strange implications for the semantics of the expression language. In fact, one could consider this a variant of SERVER-31991, but for expressions that accept named arguments rather than n-ary expressions. |
| Comment by Nicholas Zolnierz [ 31/Jan/18 ] |
|
david.storch, justin.seyster, found this while looking into |
| Comment by Ian Whalen (Inactive) [ 14/Aug/17 ] |
|
There are a number of expressions that take named arguments and right now they inherit directly from the Expression base class. Should consider this along with all of the other named expressions. |
| Comment by David Storch [ 14/Aug/17 ] |
|
This feels like scope creep to me. The agreed upon design does not specify this behavior. I also believe this to be inconsistent with the existing behavior of aggregation expressions which accept named arguments. I'm putting this back into Needs Triage for now. |