Query me this...

system.data.objects dev guy : ???Local??? Queries

system.data.objects dev guy : ???Local??? Queries — Sat, 21 Feb 2009 10:28:47 GMT

PingBack from http://blogs.msdn.com/dsimmons/archive/2009/02/21/local-queries.aspx

A disappointing behaviour in local queries of EF

Ralph's Blog — Sat, 21 Feb 2009 01:06:50 GMT

After an entity is created and added to the context it can not be queried unless it is saved to the database

re: Query me this...

Daniel Simmons - MSFT — Thu, 31 Aug 2006 15:28:58 GMT

We don't really view the context as being the same as a transaction. For that we have System.Transactions, and that is in fact a good strategy for queries that need to include not-yet-committed changes. In fact, more discussion on the original thread that motivated me to write the above blog entry resulted in this comment that I made to that thread back on the forum (copied here because I don't think I can link directly to a comment in a thread on the forum--only to the entire thread):

An unrelated discussion we were having today made me think of this thread, so I wanted to do a quick follow-up...

There is one way we didn't talk about to query uncommitted changes: Using System.Transactions. The support in this CTP is not the full thing we intend it to be before we release, but you can get it to work in some controlled scenarios today. For example (copied from an email Pablo posted internally today, so hopefully he won't mind my plagarism):

using(TransactionScope tx = new TransactionScope()) {

using(ObjectContext ctx = new ObjectContext(…)) {
var q = query…

// …make some changes on the objects returned by “q”

//…save changes without committing
ctx.SaveChanges();

//…now do more queries, they’ll include the changes you flushed

//…now commit for real, or abort if don’t want the changes to be permanent
tx.Complete();
}
}

Please tread lightly in this area with this CTP, though. There are definitely some pitfalls, but this should give you some other ideas to think about this topic in general.

- Danny

re: Query me this...

MatHobbs — Tue, 29 Aug 2006 19:29:25 GMT

Also, Hibernate has a FlushMode (see
http://www.hibernate.org/hib_docs/v3/api/org/hibernate/FlushMode.html) which provides some control over the 'precommit'/flush process when querying.

Cheers,
-Matthew Hobbs

re: Query me this...

Jaroslaw Kowalski - MSFT — Tue, 29 Aug 2006 00:49:00 GMT

Wouldn't it be possible to save dirty objects to the database automatically before running the query?

I'm the author of Sooda - simple O/R mapper for .NET (http://www.sooda.org) and it supports a concept of "precommit" in this case.

When executing a query, Sooda knows the tables/classes that the query accesses/depends on (by analyzing the WHERE clause) and issues a pre-commit of all unsaved objects of these classes. This way newly inserted objects will be properly returned by the upcoming SELECT statement. Final commit operation changes from INSERT to UPDATE on precommitted objects. Each Sooda transaction (which is equivalent to a context) is associated with an open database transaction, so partially written transactions can be cancelled if needed.

This approach has some drawbacks and complexities (like how to deal with partially constructed objects which cannot be committed because of NULLs), but I believe it is a step towards making queries really easy to use and predictable.

Would it be possible to have this implemented in EDM?

BTW. I'll be joining Microsoft in October to work for ADO.NET vNext Team as SDET. Now that you've published the CTP, I can't wait to meet you all and play with the code as we'll be obviously working on a breakthrough technology.