[CSHARP-2137] Creating index through Attributes Created: 02/Jan/18 Updated: 15/Nov/21 Resolved: 02/Feb/18 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | Serialization |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Half Legend [X] | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
I need to use a code-first programming method to establish my database. I want it to create the index automatically according to the attribute I wrote on the entity class. The java driver: spring-data-mongodb, has already supported this, and this is not hard to implement. Thank you |
| Comments |
| Comment by Robert Stam [ 02/Feb/18 ] |
|
Thanks again for making this suggestion. While the feature has appeal, the complications of actually implementing it are more than we feel are justified, at least at this point, so I'm going to close this ticket as "Won't Fix". |
| Comment by James Turner [ 06/Jan/18 ] |
|
Just want to chime in here, MongoDB indexes are quite complicated and this probably wouldn't be a small change. Most of the attributes I have seen so far for MongoDB relate to the BSON mapping however an index attribute isn't a mapping change, it is a DB change. Like what Robert mentioned, there is the question of when the driver could actually create or update the index. If it can't do it at the mapping stage (as you haven't yet defined a collection for the index to apply to), it could only reasonably do it at the stage of getting the collection from the database object. That means we could have DB queries and manipulation from simply just getting the collection object. The other thing to note is what type of index you would want the attributes to support. MongoDB has many types of indexes which act in many different ways. For example, you can have compound indexes referencing nested types compared to a single field index. Obviously the driver can already create these indexes but the problem is expressing all the different configurations and options as attributes. I actually don't think this type of change should be part of the core driver. The driver should provide all the functionality to communicate with the database and other libraries or frameworks can augment that interface to provide things like index attributes. Otherwise, the driver will get more bloated if they add every different way people want to interface with it to the database. I say all of this because I've actually written a C# MongoDB library which augments the driver which adds indexing support via attributes. In my particular case, I had to rewrite the entire way I handle entity mapping in my library to do so. Even then, its not perfect and doesn't do all the index types or options. |
| Comment by Robert Stam [ 04/Jan/18 ] |
|
Thank you for your feedback. You make a good point that if a feature is opt-in an application writer can evaluate the performance impacts and decide for themselves whether to accept them or not. It is still unclear when the driver would create an index based on attributes. As a workaround for now you can still create the indexes in your application using the existing API (just not via attributes). See the CreateOne method in the IMongoIndexManager interface (reached via collection.Indexes). |
| Comment by Half Legend [X] [ 04/Jan/18 ] |
|
As a matter of fact, I am working on a individual project based on MongoDB. It is a management tool and I don't want it to be too difficult to use. My end user will never concern about "Indexes", because they even don't know what a index is. In this case I think it will be better if there could be a attribute to create indexes. What's more, I don't think it is a good idea to refuse providing a new feature that will not break the existing structure. If this feature will affect the existing framework a lot, and may cause many issues which is working fine without the feature developed, I will not ask for a feature like that. If I need it, I will choose it. For example, Oracle provides "triggers", but in my team, we are not allowed to use "triggers", the reason is something like what you mentioned above. Anytime we need a trigger, we will "trigger" them by code. But I still think triggers is a good feature provided by Oracle even if we rejected it. Thank you very much |
| Comment by Robert Stam [ 02/Jan/18 ] |
|
We have considered this in the past but have so far decided not to implement such a feature. That's not to say we would never implement it, but for now let me share some of our reasons. 1. Indexes are more properly handled by the ops team It shouldn't normally be the responsibility of the programmer to define (in code) what indexes are required. Normally it is an ops consideration which indexes are worth creating, and also very importantly when to create them so as to not disrupt production systems at the wrong time. 2. Adding or removing an index shouldn't require releasing a new version of the application This is particularly tricky when the decision is made to remove an index that is no longer required. You could get in to a situation where ops removes the unnecessary index but the application keeps creating it again. 3. Overhead of ensuring the index exists The driver would have to at some point check whether the index exists or not and create it if necessary. It is unclear at what point in time the driver would do this, but the more often it has to do it the more overhead there would be. 4. Permissions concerns Security dictates that an application should run with the least permissions possible. Creating an index requires a very high level permission, one that would usually be better not granted to an application. I will leave this ticket open for now to encourage further discussion with the community of users. |