[SERVER-3498] Collection aliases Created: 28/Jul/11 Updated: 28/Aug/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Kenny Gorman | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 20 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||
| Description |
|
It would be nice to be able to create alias's/synonyms. The use case would be to swap out collections and/or data movement activities. For instance, fill up a collection with some data, then swap it into the spot where the application can see it. db.mycol.save( {"status":1}) ) db.mynewcol.save( {"status":0}) ) |
| Comments |
| Comment by Johnny Shields [ 28/Aug/23 ] | ||||||
|
Having used MongoDB for 10+ years, I'd love if I could hot rename some of my old collections by first creating an alias, then swapping the "primary" name. Would think MongoDB would have this feature by now. | ||||||
| Comment by Geert Bosch [ 03/Mar/20 ] | ||||||
|
There is no way why (some) non-materialized views cannot be made writeable. Determining the columns (ahem, fields) of a view that are writeable, and whether a view is insertable is a well studied topic. Having a non-materialized view with empty pipeline writable would implement aliases. We can allow a $match state by checking that a changed or inserted document matches. Then expand to projections etc. Even a union view can be insertable/modifiable as long as all sources have disjoint matches on them. At that point you can implement sharding using writable views. | ||||||
| Comment by Jan Curn [ 28/Feb/20 ] | ||||||
|
Big +1 for this feature. As our production database at Apify evolves, we'd like to fix some old bad naming decisions to keep the database tidy, maintainable and easy to understand for new engineers. With collection aliases, renaming the collections would be easy. Doing it now means a lot of engineering complexity and downtime for our users. | ||||||
| Comment by Asya Kamsky [ 01/Mar/18 ] | ||||||
|
Alias should be usable for reads and writes - in other words, transparent to the client. If the use case is for read-only then read-only views can address that - you can even redefine a view definition to point to a different underlying collection without any downtime (existing operations on previous definition will complete, but new ones will correctly read the new underlying collection). | ||||||
| Comment by Geert Bosch [ 01/Mar/18 ] | ||||||
|
This is implemented by read-only views:
With a non-empty pipeline this can in particularly be useful for changes in the dataformat: you can see the same physical collection in both formats at the same time, allowing for backward compatibility. | ||||||
| Comment by Peter Vandercappellen [ 23/Oct/17 ] | ||||||
|
+1 for this feature. And it would be nice to have aliassen for databases as well. | ||||||
| Comment by VenkataRamaRao Surapaneni [ 03/Nov/16 ] | ||||||
|
Yes we use ES aliases a lot for index rollovers. I am requesting a same kind of feature in mongoDB that application should always r/w only through "alias" and the collections (sharded or unsharded) underlying the aliases can be added or removed atomically without changing any application DB connection string. this is useful for our monthly, quarterly collection rollovers for time-series data. +1 | ||||||
| Comment by Sylvain Laurent [ 03/Mar/16 ] | ||||||
|
+1 | ||||||
| Comment by Michael Korbakov [ 30/Jun/15 ] | ||||||
|
+1 for this feature. Implementing it will make long-term support for MongoDB deployments easier. In many cases it also allows to decouple applications from old data retention and archiving logic. Check ElasticSearch, they have tons of good use-cases for aliases. | ||||||
| Comment by Andrew Doumaux [ 25/Jun/15 ] | ||||||
|
I think this could be a very useful feature, and might be able to get around some of the issues associated with not being able to rename sharded collections |