Wednesday, 30 May 2012
Wednesday, 16 May 2012
It seems that every time EF creates a DB migration it stores some kind hash of the current database schema which is then used before to the migration is actually executed to make sure that the database is in the right state. This breaks down very quickly when more than 1 developer works on the model. Sample scenario:
- Dev1 adds migration for a new property called Master and pushes the change.
- Dev2 adds migration for AnotherDev property and applies it to the database
- Dev2 pulls Dev1’s changes
- Dev2 tries to run the app and gets an exception.
- Dev2 needs to delete his migration and rollback corresponding changes in the database
- Dev2 applies Dev1’s migration
- Dev2 adds again migration for AnotherDev property
- Dev2 is ready to push his changes unless someone else introduced a new migration in the meantime. In such case Dev2 goes back to step number 4.
EF has a chance to become a decent ORM with even better tooling but before this happens EF team needs to understand that developers know what they do and prefer to have more than less rope at their disposal.
I’m happy with the product to be safe by default but there should be a way of disabling those annoying limitations. Without this ability Scott Hanselman idea of LEGO size building blocks is….well just an idea when it comes to EF.
Sunday, 6 May 2012
I’ve been using VirtualBox for over a year and I’m pretty happy with it but I wanted to see if new releases of VMware and Parallels can give me even better IO performance. This is a very simple and coarse test but it clearly indicates that I should give VMware a try.
- Guest: Windows 7 64bit SP1
- Guest: 8 CPUs and 4GB of RAM
- Guest: Vendor specific additions installed
- VMware: Workstation 8.0.3
- Parallels: Workstation 6.0.13950
- VirtualBox: 4.1.12
- CrystalDiskMark 3.0.1c was run 3 times for each app + host