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?
Related
I'm programming my fist SwiftApp got stuck setting up Core data. Since I'm integrating it into existing code I can't have Xcode set it up on Prohect init anymore. Furthermore I als want to understand what the lines of code actually do. Since all Core libraries are secret I am stuck with Apple's Docs which are not very clear on the matter.
Pfew... with that out of the way here is the question; What is the significance of the name passed to...
let container = NSPersistentContainer(name: "Core_Data")
...in the App Delegate file. I had set it up before but during compilation Xcode complained that it could not find the specified Name's module. Changing it to my project's name, the core data file I had created or the name of the Database passed to the menu when adding a Core Data file did not seem to help at all. Searching the web and a few tutorials people just fly over it and it is still very much unclear to me.
Any help would be much appreciated!
The string passed there is used for two things. If you were to pass the string Foo, Core Data would attempt:
To find the data model by looking for Foo.xcdatamodel or Foo.xcdatamodeld.
To find (or create) the persistent store, using the name Foo.sqlite.
Even an incorrect string value (i.e. one that doesn't match the name of your data model) should not cause a compilation error. It might cause an error at run time if iOS can't find the named data model.
I recently upgraded a relatively old System TYPO3 4.7 => 6.2.
I changed alot of namespaces/imports etc. and fixed stuff here and there. After the system was stable I made some changes in the extension builder and added some new fields.
I had to change some code in some files that threw errors but after that I was able to successfully save in the extension builder.
It added the correct classes,attributes and actions but now the system shows me this error:
1247602160: Table 'keepins_upgrade.tx_extbase_persistence_objectstorage' doesn't exist
Usually this error is related to models that are mapped incorrectly in the typoscript file but this seems different.. any suggestions?
Shot from the hip: you have one or more properties in your domain model which is annotated incorrectly - so it is read as a 1:1 relation to ObjectStorage, not a 1:n to a collection of another object. Or, less likely given your previous version, you've annotated a setter method or controller action so it requires an instance of ObjectStorage, but neglected to add PHPDOC that defines the true expected child type or is somehow else invalid or not connected to the right property.
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.
I am seeing something in Entity Framework that has me thinking that I either completely misunderstand how the database context works, or EF is actually broken (and I know that most likely means I just don't get it).
Consider the following scenario:
In the database I have a bunch of Student Attendance records, and they all have a code marked as P for present.
Then we have something akin to the following:
public void SetAttendance(int dayId,int attendanceId, int attendanceId, String mark)
{
updateAttendance = new StudentAttendance()
{
Code=String.Empty,
AttendanceId=attendanceId,
DayId = dayId
};
context.Attach(updateAttendance);
//I don't save changes yet because I now need to do some logic
var markedAttendanceCount = context.StudentAttendance.Where(att=> !String.IsNullOrEmpty(att.Code) && att.DayId == dayId).Count();
var allAttendanceCount = context.StudentAttendance.Where(att=> att.DayId == dayId).Count();
var updateDay = new ClassDay()
{
DayId = dayId,
AllMarked = markedAttendanceCount = allAttendanceCount
};
context.Attach(updateDay);
context.SaveChanges();
}
I would expect that if I were to call that SetAttendance method as follows:
myworker.SetAttendance(10,20,String.Empty);
That it should properly recognize that the attendance for the day is not fully marked. What I am instead seeing is that my look int query against context.StudentAttendance is asking the database. As such, my detection of the day's status change is always one behind.
I thought that the context was basically supposed to be smart enough to let you write something like this. In essence, I had always had the impression that the db context lets you essentially work with a serializable transaction kind of behavior. As you make changes to the data through your context, those changes will reflect in queries against the context. Am I missing something?
EF doesn't work that way, no. For performance reasons basically.
However, context.StudentAttendance.Local exposes a set containing the added entities. It also contains any entity previously loaded by the context in a query. If you like you can load the whole DbSet into memory as described here: https://msdn.microsoft.com/en-au/data/jj592872.aspx however this is not advisable for large datasets.
Also, you should be using context.Add() rather than context.Attach(). The latter is for entities which already exist in the database.
It's true that you don't fully understand how EF works, but I think EF is to blame for that. You're asking a very good and valid question.
NHibernate, as opposed to EF, has this AutoFlush feature. This means that "at any moment" it may commit changes to the database in order to keep local changes and database content in sync without the developer's intervention. In your case, it would have saved the new StudentAttendance before querying existing ones from the database. So if the new one matched the predicate (DayId == dayId) it would have contributed to allAttendanceCount. This feature, when understood well, allows for a very intuitive way of dealing with data, exactly the way you expected EF to behave.
The truth is, however, that AutoFlush has always eluded developers, so they often just disabled it. As a developer you want to have full control, you don't want to depend on some smart feature that seems to have a life of its own. (Even though the reality is that you probably just didn't take the time to fully get it).
I can imagine that for this reason, the EF team decided not to implement such a feature.
So what to do in your case? Not easy. When after adding the new StudentAttendance you'd do...
context.StudentAttendance.Load();
(assuming that you have a DbContext, though your "context.Attach" doesn't seem to be in line that).
And then...
var allAttendanceCount = context.StudentAttendance
.Local // <= Local! Includes the new item
.Where(att=> att.DayId == dayId)
.Count();
...you'd have the desired result. But of course, loading all StudentAttendance records locally is a tremendous overkill.
One simple alternative is to to the count as you do now and add 1 to it.
Another alternative is to mimic autoflush, sort of, and save the new StudentAttendance before doing the count. But then you'd have to wrap everything in a TransactionScope. One advantage is that you'd have the very latest value of allAttendanceCount.
We've generated ~80 migrations since the release of the 4.3.x version of Entity Framework. Each time we generate a new migration, EF gens a snapshot of the current model for the IMigrationMetadata.Target property.
Since each migration is adding ~135k characters to our assembly, we are starting to hit critical mass. We're now receiving a "No logical space left to create more user strings." compiler error. Combine that w/ the pre-compile views, and you've got a lot of strings.
What's the best long term approach to using EF migrations with a complex model?
Maybe add-migration should be generating these w/ resource files.
we had the same issue. We are also fix this using moving the generated string into resource:
public sealed partial class RegionalCenterRenameClass : IMigrationMetadata
{
// Skipped code
string IMigrationMetadata.Target
{
get { return Targets.M201207110918331_RegionalCenterRenameClass; }
}
}
where Targets - is resource file (resx).
Thanks for reporting this. I have added this issue to our backlog for EF6.
For now, replacing the string with a resource lookup is the best workaround I can think of.