-
Notifications
You must be signed in to change notification settings - Fork 56
Caveats & Limitations
EFCore-MongoDB is currently in pre-release, and will not be available as a "fully stable" release until after the EntityFramework Core platform has full support for Complex Types. This may mean that any application using EFCore-MongoDB will be consuming an "unstable" pre-release package for quite some time. Every effort will be made to ensure that pre-release versioning reflects any potentially breaking changes so that early adopters and contributors don't find their code breaking when pulling CI builds.
Once EF Core has released full support for Complex Types, EFCore-MongoDB's versions will be updated to reflect to the current version of the EF Core framework.
MongoDB is a No-SQL database, meaning that it provides no guaranteed schema for documents. As such, MongoDB performs little to no validation beyond simple indexes, which may include uniqueness constraints on one or more document fields.
Because there is no schema, it can be expensive to determine the general model for the data in an existing database. Every document in every collection must be scanned to extract its keys in order to ensure that all known fields have been collected. Even then, determining the relationship between fields would come down to an educated guess at best.
For example, some data architectures may require a document to reference documents in other collections. In this scenario, there is no server-side metadata to indicate the related collections: the process of navigating inter-collection relationships is handled purely by the client framework.
Some architectures may also employ certain conventions that ignore empty or default field values on insert. The values of such fields are inferred by the client-side framework when querying the database, and there is no server-side metadata to indicate the intended defaults.
Likewise, some architectures may store polymorphic document hierarchies within a single collection. In such a case, documents within the same collection may have greatly varying fields, with no server-side metadata to reflect which fields belong to which discriminators. Without access to the client framework code, it would be impossible to distinguish between whether a field is missing from one document because it's only a member of a different sub-hierarchy, or because it was set to its default value.
This list highlights the most common schematic problems with MongoDB document data, but it is hardly exhaustive. Because of these issues, it is impossible to accurately and intelligently extract a model from an existing database instance. Therefor, EFCore-MongoDB does not support database scaffolding, and there are no plans to do so in the future.
While MongoDB does not have support for schemas, it does have rich facilities for database and collection administration including renaming collections and fields, changing indexes, and even changing data types. As such, data versioning and migrations are fully possible with MongoDB. Exposing these facilities through EFCore-MongoDB is currently on the backlog.