[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.
However, what need to do is to add a new attribute, nothing else will be changed.

If I need it, I will choose it.
If it will break my project, I will reject it.
It's up to me, instead of the framework itself.

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.

Generated at Wed Feb 07 21:41:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.