在我的应用程序中，我通过AddObject方法将一个实体添加到TableServiceContext中。在稍后的过程中，我想查询TableServiceContext以检索此特定实体以更新某些属性，但该查询未给出结果。如果我在AddObject之后立即执行SaveChanges，它只会给我一个结果。这意味着我有一个额外的往返服务器。我想创建和更新实体，然后调用SaveChanges将实体持久化到Azure表存储。在添加对象后查询Azure TableServiceContext不会产生结果
有没有人知道为什么我查询上下文时没有得到结果？有没有办法如何从上下文中获取实体，而无需额外调用SaveChanges？
感谢
罗纳德
AddObject刚刚开始跟踪在本地内存中的对象，所以这对我来说很有意义该查询表存储它不会返回。 （表存储器不知道它。）我想说，如果你想这样做，你应该自己跟踪新的实体。
我对这个场景有点困惑。这听起来像你想这样的事情（不工作）：
var foo = new Foo();
context.AddObject("foo", foo);
...
foo = context.CreateQuery<Foo>("foo").Where(...).Single();
foo.bar = "baz";
context.UpdateObject(foo);
context.SaveChanges();
为什么不这样更换？
var foo = new Foo();
...
foo.bar = "baz";
context.AddObject("foo", foo);
那你的代码，让你必须去通过TableServiceContext让你创建的对象？
听起来就像你在这里尝试Upsert。你见过对InsertOrReplace的支持吗？还有InsertOrMerge，但我认为你正在覆盖。
您正在解释的情况几乎是正确的，您的建议将对我有用。在我的场景中，对象可能已经存在于表存储器中，所以我只创建一个对象，如果它还不存在。因此，在“新”声明之前，我首先进行查询。但在我看来，TableServiceContext就像一个容器。那么为什么我必须在这个容器外面保留一个引用，以便在稍后阶段进行更新。为什么不问容器拿到物体呢？也许我对TableServiceContext的想法是错误的。如果是这样，你能提出一些关于这方面的进一步阅读？谢谢，罗纳德。 – Ronald
我认为把'TableServiceContext'看作一个容器可能是个错误。它确实跟踪事情，但仅用于了解发送到存储服务的更改要发送的内容。对不起，我没有一个更好的思维模式来思考它。 – smarx