Something I ran into recently.
I have a project which dynamically generates connection strings and I'm trying to use MigrateDatabaseToLatestVersion on the context that wraps these. Every time I would do this I would see my dynamic db not be created, but instead the db on my default constructor connection string (used for testing) migrated over and over.
After digging through the EF migrations source code I find that MigrateDatabaseToLatestVersion has a constructor
// Summary:
// Initializes a new instance of the MigrateDatabaseToLatestVersion class specifying
// whether to use the connection information from the context that triggered initialization
// to perform the migration.
//
// Parameters:
// useSuppliedContext:
// If set to true the initializer is run using the connection information from the
// context that triggered initialization. Otherwise, the connection information
// will be taken from a context constructed using the default constructor or registered
// factory if applicable.
public MigrateDatabaseToLatestVersion(bool useSuppliedContext);
Not being flippant but what is the reason why you would want to ever migrate the context that is not the one that is being migrated? Why is that the default? Does anyone have any insight into the thinking here?
I want to know the answer to this question myself. I do not know why the context was designed that way. However, I can venture a guess as to why the current default is useSuppliedContext=false.
I decompiled the first version of EntityFramework to include migration support, EntityFramework-4.3.0, because I suspect that the default behavior is for backwards compatibility purposes. I looked at the decompiled implementation of IDatabaseInitializer<TContext>.InitializeDatabase(TContext context) in MigrateDatabaseToLatestVersion. Guess what? In EntityFramework-4.3.0, the context parameter of that method is completely ignored. So it can’t possibly respond to explicitly-provided connection parameters/settings because those are only accessible through that context variable.
It looks like support for respecting context was added in EntityFramework-6.1.1. Prior to that, your only option was to pass a connection string to MigrateDatabaseToLatestVersion’s constructor. I think this would have prevented you from using the same DbContext type for different backends in the same process. I bet that the new feature of respecting the context (and behaving correctly, IMO) would not have been accepted into EntityFramework if it was enabled by default because that would change behavior which stable projects may be relying on and otherwise prevent projects from adopting it.
The exact reasoning is actually given as a comment in commit 777a7a77a740c75d1828eb53332ab3d31ebbcfa3 by Rowan Miller:
Also swapping the new useSuppliedContext parameter on MigrateDatabaseToLatestVersion`.cs to be false by default since we are going to be shipping this change in a patch release.
Related
With the release of the .TagWithCallSite() method in EF Core 6.0 I was wondering if there is a way to apply this globally on every query run via a DbContext in some way?
It would be much better to apply this across the whole project without having to put it on each query individually.
TagWithCallSite accepts parameters marked with CallerFilePathAttribute and CallerLineNumberAttribute which are filled in by compiler (or manually if needed) during build so it is impossible to set up globally.
No, you cant't do that.
When you explicitly define TagWithCallSite(), complier automatically fills default parameters filePath and lineNumber. It is not possible to define that for all queries because compiler do not store such information in Expression Tree.
i'm currently working on a solution to setting metric tags for the microprofile fault-tolerance framework. We're using it together with metrics, but one cannot directly set tags via the fault-tolerance annotations.
So we came up with a workaround setting a ThreadLocal value via an Interceptor, which then is read by a custom ConfigSource. The ConfigSource checks for "mp.metrics.tags" and "MP_METRICS_TAGS" config keys in it's getValue(final String propertyName) method. This would basically work if the getValue would get called every time a fault-tolerance annotation is processed. But is seems like this is not the case and the invocations of the method happen randomly.
In my oppinion ConfigSources and their getValue(final String propertyName) should always get called as a developer might rely on config values which could change every second.
Any ideas why the config source is not called?
It looks like the custom ConfigSource does no longer get called when returning null multiple times or at least during the server startup phase. In the mentioned scenario this can be bypassed by returning an empty string. Then the ConfigSource also gets called for every getValue() method call at runtime.
The MicroProfile Config 1.4 specification indicates that no caching of a ConfigSource's value should occur, so if your MicroProfile Config Config implementation (you don't say which implementation it is) is caching the results of a call to ConfigSource#getValue() it is not compliant, as best as I can tell (the specification is flawed, not very rigorous, and its TCK is spotty but it certainly seems to be pretty clear on this issue).
(Do note that a given ConfigSource implementation may, of course, decide to return cached values from its getValue() method.)
I am trying to set up an initializer used in a test environment. From everything I read, DropCreateDatabaseIfModelChanges is exactly what I need. Often times the database gets slightly out of sync with the model, and I need to simply start over fresh.
So here is how I went about setting up my context constructor
public ApplicationContext(int dbID, string username) : base(dbID, username)
{
Database.SetInitializer<ApplicationContext>(new DropCreateDatabaseIfModelChanges<ApplicationContext>());
Database.Initialize(true);
}
However, even when I have this initializer set up, I still get the error:
"The model backing the "ApplicationContext" has changed since the database was created. Consider using code first migrations to update
the database"
some other things to note:
I have tried setting AutomicMigrationsEnabled = false as well as true in my Migrations config file.
I have tried with and without forcing initialization
Anybody run into the same issue or have any ideas?
UPDATE
I was able to look through the source code for System.Data.entity here:
https://github.com/hallco978/entityframework/tree/master/src/EntityFramework
It turns out I needed to outright delete my Migrations/Configuration.cs file to prevent the error. It doesn't matter what the settings are within that configuration file.
I know get a problem because I can't drop the database if I'm using it. Does anyone know if the DeleteDatabase actually means drop the entire database or just the tables the model created?
I have created a custom serializer for mongoDB.
I can register it and it works as expected.
However the my application sometimes throws an error because it tries to register the serializer twice.
How do I detect whether a serializer has already been registered and thus stop my application from registering a second time?
If you are using
BsonSerializer.RegisterSerializer(typeof (Type), typeSerializer);
you might get this error "there is already a serializer registered for type". Because you cannot register the same type of serializer 2 times. But you can write your own serializer and this serializer will work before default serializers.
For instance: if you want to use local DateTime instead of Utc which is default.
all you need to do is that writing a class implementing IBsonSerializationProviderand register this provider to BsonSerializer as soon as possible!
here is the sample code.
public class LocalDateTimeSerializationProvider : IBsonSerializationProvider
{
public IBsonSerializer GetSerializer(Type type)
{
return type == typeof(DateTime) ? DateTimeSerializer.LocalInstance : null;
}
}
and to be able to register
BsonSerializer.RegisterSerializationProvider(new LocalDateTimeSerializationProvider());
I hope this helps, you can also read the original documentation in here
this .net driver version of mongodb is 2.4!
TL;DR: Ig you are lazy, use BsonSerializer.LookupSerializer or BsonMemberMap.GetSerializer. To do it right, make sure the registration code is called once and only once.
The best approach to avoid this is to make sure the serializer is registered only once. It's a good idea to have some global startup code that registers anything that is global to the application once, and only once. That includes stuff like dependency injector configuration, tools like automapper and the mongodb driver. If you call this code only once and from a single point in code, you don't need to worry about thread safety, dead locks or similar troubles.
The MongoDB driver configuration settings are thread-safe, but don't assume that this is true for all software packages that you might need to configure. Also, locking can be very expensive performance wise if your code is multi-threaded, for instance in a web-application. Last but not least, that lookup you're doing might not be trivial in the first place, because some methods need to walk an entire inheritance tree.
We have to deal with production and test connection strings in our environment. Database First Solution.
I have an extremely picky client that is not happy with the fact that you can create a partial class with a second constructor with a parameter, or inherit from the named Entities class with an empty parameter constructor.
He claims that a developer could unknowingly use the base constructor.
Is there any way to modify the generated constructor, or set an option so that the base constructor does not get generated, so we can write our own?
Thanks!
If you are using T4 template for context generation you can do whatever you want. For example:
Make your context sealed
Remove partial keywork from generated context class
Define constructor you want directly in the template
The only thing you need to do is modify the ModelName.Context.tt template.
Anyway your client should concentrate on business requirements and not on stupid assumption about coding.
He claims that a developer could unknowingly use the base constructor.
I claim that this can happen but it is not an issue if your application is correctly tested and if you make code review for new team members or junior developers.