[SERVER-54044] Investigation on removing the usage of command aliases Created: 26/Jan/21 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Rishab Joshi (Inactive) | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
Currently, the Command class supports having aliases for command-names. For eg, the FindAndModify command could be invoked by specifying either findAndModify or findandmodify. Here findAndModify is the latest name for this command and findandmodify is the older name. API versioning by design does not support having aliases, ie. each command in the API version should have only one command. But to support backward compatibility, a ticket to support command aliases has been created: Although the IDL generated classes will now have support for aliases, we should still get rid of aliases, to have a tighter design around API versioning. Developers might be tempted to add aliases in the near future if we continue to support and it will become more difficult to get rid of aliases. We could do the followings:
|