Is there a way similar to Database.EncureCreated() method to ensure all migrations were executed from the app?
You can use Database.Migrate() - REF
From the article:
Applies any pending migrations for the context to the database. Will create the database if it does not already exist.
Note that Database.Migrate() is mutually exclusive with Database.EnsureCreated()
I usually allow EF to manage the transactions. In this case I am using one context but I am making multiple calls to stored procedures using FromRawSql and ExecuteSqlRaw. I'm not sure if this will be safely done in a transaction since I don't usually use stored procedures. If a procedure fails will all the procedures be rolled back? Do I need to explicitly create a TransactionScope?
Is there a difference between the two?
For example within a hibernate transaction we can access the database, run some java code and then access the database again. We can't do that within a transaction done via SQL can we? Is this the difference?
The 2 directly relate to each other - a Hibernate transaction maps to and controls the JDBC (database) transaction.
You can do the same thing with direct JDBC / SQL, without Hibernate - though you'll need to call Connection.setAutoCommit(false) to get started. Otherwise, by default, a commit is called after each statement - making each statement run in its own transaction.
Some additional details are available at http://docs.oracle.com/javase/tutorial/jdbc/basics/transactions.html.
I have tried to google this question without finding any answers.
I am trying to batch update/insert entities in a wcf, entity frame work project.
My question is does Entity Framework 4.1(code first) support batch insert, update and delete?
And if ef 4.1 does support cud, do you have any examples?
Entity framework (all versions) supports CUD (insert, update, delete) but it doesn't support batching commands. It means that each insert, update and delete are executed in separate roundtrip to the database.
This has no relation to WCF. If you want batching over WCF you just need to send collection of objects for processing and let them process on the server by EF (without batching). WCF data services supports batching for passing multiple objects to server within one roundtrip.
Consider a regular web application doing mostly form-based CRUD operations over SQL database. Should there be explicit transaction management in such web application? Or should it simply use autocommit mode? And if doing transactions, is "transaction per request" sufficient?
I would only use explicit transactions when you're doing things that are actually transactional, e.g., issuing several SQL commands that are highly interrelated. I guess the classic example of this is a banking application -- withdrawing money from one account and depositing it in another account must always succeeed or fail as a batch, otherwise someone gets ripped off!
We use transactions on SO, but only sparingly. Most of our database updates are standalone and atomic. Very few have the properties of the banking example above.
I strongly recommend using transaction mode to safe data integrity because autocommit mode can cause partial data saving.
This is usually handled for me at the database interface layer - The web application rarely calls multiple stored procedures within a transaction. It usually calls a single stored procedure which manages the entire transaction, so the web application only needs to worry about whether it fails.
Usually the web application is not allowed access to other things (tables, views, internal stored procedures) which could allow the database to be in an invalid state if they were attempted without being wrapped in a transaction initiated at the connection level by the client prior to their calls.
There are exceptions to this where a transaction is initiated by the web application, but they are generally few and far between.
You should use transactions given that different users will be hitting the database at the same time. I would recommend you do not use autocommit. Use explicit transaction brackets. As to the resolution of each transaction, you should bracket a particular unit of work (whatever that means in your context).
You might also want to look into the different transaction isolation levels that your SQL database supports. They will offer a range of behaviours in terms of what reading users see of partially updated records.
It depends on how is the CRUD handling done, if and only if all creations and modifications of model instances is made in a single update or insert query, you can use autocommit.
If you are dealing with CRUD in multiple queries mode (a bad idea, IMO) then you certainly should define transactions explicitly, as these queries would certainly be 'transactionally related', you won't want to end with a half model in your database. This is relevant because some web frameworks tend to do things the 'multiple query' way for various reasons.
As for which transaction mode to use it depends on what you can support in terms of data views (ie, how current the data needs to be when seen by clients) and what you'll have to support in terms of performance.
it is better to insert/update into multiple tables in a single stored procedure. That way, there is no need to manage transactions from the web application.