Querying Azure TableServiceContext after adding object gives no result - azure

In my application I am adding an entity to a TableServiceContext through the AddObject method. Later in the proces I want to query the TableServiceContext in order to retrieve this specific entity in order to update some properties, but the query doesn't give me a result. It will only give me a result if I do a SaveChanges immediately after the AddObject. This means that I have an extra roundtrip to the server. I would like to create and update the entity, and then call a SaveChanges to persist the entity to Azure Table Storage.
Does anyone know why I don't get a result when querying the context? Is there a way how to get the entity from the context without the extra call to SaveChanges?
Thanks
Ronald

Sounds like you are trying to Upsert here. Have you seen the support for InsertOrReplace? There is also InsertOrMerge, but I think you are looking to overwrite.
http://msdn.microsoft.com/en-us/library/hh452242.aspx

AddObject just starts tracking the object in local memory, so it makes sense to me that querying table storage for it doesn't return it. (Table storage has no knowledge of it.) I'd say that if you want to do this, you should just keep track of the new entity yourself.
I'm a bit confused as to the scenario. It sounds like you want something like this (won't work):
var foo = new Foo();
context.AddObject("foo", foo);
...
foo = context.CreateQuery<Foo>("foo").Where(...).Single();
foo.bar = "baz";
context.UpdateObject(foo);
context.SaveChanges();
Why not replace with this?
var foo = new Foo();
...
foo.bar = "baz";
context.AddObject("foo", foo);
What about your code makes you have to go through the TableServiceContext to get at the object you created?

Related

MikroORM: How to use 'insert_id' for subsequent persists?

How can I get the insert_id (or existing id on duplicate key error) from a persist? I'd like to use it in following persists before flush.
In my mind, even though the EntityManager doesn't have an id yet, it could still populate that and use it during flush, but I think my thinking is flawed here, I'm new to MikroORM. From what I can see in the docs, I can only achieve this using the Query Builder.
Thanks for your help!
You can just build the entity graph, the entity does not need to have a PK to be used in a relation:
const book = new Book(); // new entity, no PK
user.favorites.push(book); // doesnt matter if it has PK
await em.flush(); // if `user` was a managed entity, this will find the new book and save it to the database
console.log(book.id); // now we have the PK available on entity
In other words, the entity instance is what holds the identity, you use that, not the PK.

Is there a way to configure Azure Table updates to preserve future/unknown properties/columns?

Suppose I create a model
public class Foo :TableEntity {
public int OriginalProperty {get;set;}
}
I then deploy a service that periodically updates the values of OriginalProperty with code similar to...
//use model-based query
var query = new TableQuery<Foo>().Where(…);
//get the (one) result
var row= (await table.ExecuteQueryAsync(query)).Single()
//modify and write it back
row.OriginalProperty = some_new_value;
await table.ExecuteAsync(TableOperation.InsertOrReplace(row));
At some later time I decide I want to add a new property to Foo for use by a different service.
public class Foo :TableEntity {
public int OriginalProperty {get;set;}
public int NewProperty {get;set;}
}
I make this change locally and start updating a few records from my local machine without updating the original deployed service.
The behaviour I am seeing is that changes I make to NewProperty from my local machine are lost as soon as the deployed service updates the record. Of course this makes sense in some ways. The service is unaware that NewProperty has been added and has no reason to preserve it. However my understanding was that the TableEntity implementation was dictionary-based so I was hoping that it would 'ignore' (i.e. preserve) newly introduced columns rather than delete them.
Is there a way to configure the query/insertion to get the behaviour I want? I'm aware of DynamicTableEntity but it's unclear whether using this as a base class would result in a change of behaviour for model properties.
Just to be clear, I'm not suggesting that continually fiddling with the model or having multiple client models for the same table is a good habit to get into, but it's definitely useful to be able to occasionally add a column without worrying about redeploying every service that might touch the affected table.
You can use InsertOrMerge instead of InsertOrReplace.

Entity Framework Code First check Database exist

In Entity Framework Code first i want to check database is exist before create Database.
In code first when i call Entities dc = new Entities() then it goes to OnModelCreating and generate Database. How can i check if the Database exists in Entity framework Code first?
You can do:
using(var dbContext = new MyContext())
{
if (!dbContext.Database.Exists())
dbContext.Database.Create();
}
Edit:
Following the colegue sugestion, the meaning of this code is very simple: Supose your context constructor is not set to create the database, so before sending any database operations, you can check if it exists, if not, you can create a new one with the connection string parameters being the rules for the creation.
This would be a static alternative, that works even without creating the DbContext first:
System.Data.Entity.Database.Exists(dbNameOrconnectionString);

How to add a reference to table to userdata object?

I have a function in lua that accepts a userdata object.
function Class:AttachToUserdataObject(userdataObject)
userDataObject.tableAttached = self
end
But later on, when I am using the same userdata object, I can't find it - userdataObject.tableAttached is nil. I feel like I don't fully understand the way userdata objects work yet.
Is there any way of binding the object to userdata other than creating a global table that has ids of all userdata objects (they have unique id) and references to tables?
I would like to keep it as elegant as I can, but without the access to C++ code I guess I can sacrifice some elegancy if it just works.
A userdata object does not have fields like a table and Lua has no knowledge whatsoever about internals of the underlying C object. In order to achieve what you want, you'd have to handle the __index and __newindex metamethods.
So, for example, when doing the assignment like userdataObject.tableAttached = self, the __newindex metamethod is triggered. Inside it, you could just store the value in the metatable itself (subject to a possible name collision) or in another table, which itself is stored in the metatable.
To retrieve the data back, you'd have to handle the __index metamethod. It can get a bit tricky with userdata, so let me know, if you run into problems.
You could use a backing weak table instead:
local _data = setmetatable({}, {__mode='k'})
function Class:AttachToUserdataObject(userdataObject)
_data[userDataObject] = self
end

CRM 2011 Plugin - Does using early bound entities for attribute names cause memory issues?

In my plugin code, I use early bound entities (generated via the crmsvcutil). Within my code, I am using MemberExpression to retrieve the name of the property. For instance, if I want the full name of the user who initiated the plugin I do the following
SystemUser pluginExecutedBy = new SystemUser();
pluginExecutedBy = Common.RetrieveEntity(service
, SystemUser.EntityLogicalName
, new ColumnSet(new string[] {Common.GetPropertyName(() => pluginExecutedBy.FullName)})
, localContext.PluginExecutionContext.InitiatingUserId).ToEntity<SystemUser>();
The code for GetPropertyName is as follows
public static string GetPropertyName<T>(Expression<Func<T>> expression)
{
MemberExpression body = (MemberExpression)expression.Body;
return body.Member.Name.ToLower();
}
The code for RetrieveEntity is as follows
public static Entity RetrieveEntity(IOrganizationService xrmService, string entityName, ColumnSet columns, Guid entityId)
{
return (Entity)xrmService.Retrieve(entityName, entityId, columns);
}
My solution architect's comments:
Instead of writing the code like above, why not write it like this (hardcoding the name of the field - or use a struct).
SystemUser pluginExecutedBy = null;
pluginExecutedBy = Common.RetrieveEntity(service
, SystemUser.EntityLogicalName
, new ColumnSet(new string[] {"fullname"})
, localContext.PluginExecutionContext.InitiatingUserId).ToEntity<SystemUser>();
Reason:
Your code unnecessarily creates an object before it requires it (as you instantiate the object with the new keyword before the RetrieveEntity in order to use it with my GetProperty method) which is bad programming practice. In my code, I have never used the new keyword, but merely casting it and casting does not create a new object. Now, I am no expert in C# or .NET, but I like to read and try out different things. So, I looked up the Microsoft.Xrm.Sdk.dll and found that ToEntity within Sdk, actually did create a new Entity using the keyword new.
If the Common.Retrieve returns null, your code has unnecessarily allocated memory which will cause performance issues whereas mine would not?
A managed language like C# "manages the memory" for me, does it not?
Question
Is my code badly written? If so, why? If it is better - why is it? (I believe it is a lot more cleaner and even if a field name changes as long as as the early bound class file is regenerated, I do not have to re-write any code)
I agree that cast does not create a new object, but does my code unnecessarily create objects?
Is there a better way (a completely different third way) to write the code?
Note: I suggested using the GetPropertyName because, he was hard-coding attribute names all over his code and so in a different project which did not use early bound entities I used structs for attribute names - something like below. I did this 3 weeks into my new job with CRM 2011 but later on discovered the magic of MemberExpression. He was writing a massive cs file for each of the entity that he was using in his plugin and I told him he did not have to do any of this as he could just use my GetPropertyName method in his plugin and get all the fields required and that prompted this code review comments. Normally he does not do a code review.
public class ClientName
{
public struct EntityNameA
{
public const string LogicalName = "new_EntityNameA";
public struct Attributes
{
public const string Name = "new_name";
public const string Status = "new_status";
}
}
}
PS: Or is the question / time spent analyzing just not worth it?
Early Bound, Late Bound, MemberExpression, bla bla bla :)
I can understand the "philosophy", but looking at your code a giant alarm popup in my head:
public static Entity RetrieveEntity(IOrganizationService xrmService, string entityName, ColumnSet columns, Guid entityId)
{
return (Entity)xrmService.Retrieve(entityName, entityId, columns);
}
the Retrieve throws an exception if the record is not found.
About the other things, the GetPropertyName is ok, but are always choices, for example I try to use always late bound in plugins, maybe in a project I prefer to use early bound, often there is more than one way to resolve a problem.
Happy crm coding!
Although GetPropertyName is a quite a clever solution I don't like it, and that's entirely to do with readability. To me its far easier to understand what is going on with: new ColumnSet(new string[] {"fullname"}).
But that's pretty much personal preference, but its important to remember that your not just writing code for yourself you are writing it for your team, they should be able to easily understand the work you have produced.
As a side a hardcoded string probably performs better at runtime. I usually hardcode all my values, if the entity model in CRM changes I will have to revisit to make changes in any case. There's no difference between early and late bound in that situation.
I don't understand the point of this function,
public static Entity RetrieveEntity(IOrganizationService xrmService, string entityName, ColumnSet columns, Guid entityId)
{
return (Entity)xrmService.Retrieve(entityName, entityId, columns);
}
It doesn't do anything (apart from cast something that is already of that type).
1.Your code unnecessarily creates an object before it requires it (as you instantiate the object with the new keyword before the
RetrieveEntity in order to use it with my GetProperty method) which is
bad programming practice. In my code, I have never used the new
keyword, but merely casting it and casting does not create a new
object.
I believe this refers to; SystemUser pluginExecutedBy = new SystemUser(); I can see his/her point here, in this case new SystemUser() doesn't do much, but if the object you were instantiating did something resource intensive (load files, open DB connections) you might be doing something 'wasteful'. In this case I would be surprised if changing SystemUser pluginExecutedBy = null; actually yielded any significant performance gain.
2.If the Common.Retrieve returns null, your code has unnecessarily allocated memory which will cause performance issues
I would be surprised if that caused a performance issue, and anyway as Guido points out that function wont return null in any case.
Overall there is little about this code I strongly feel needs changing - but things can be always be better and its worth discussing (e.g. the point of code review), although it can be hard not to you shouldn't be precious about your code.
Personally I would go with hardcoded attribute names and dump the Common.RetrieveEntity function as it doesn't do anything.
pluginExecutedBy = service.Retrieve(SystemUser.EntityLogicalName, localContext.PluginExecutionContext.InitiatingUserId, new ColumnSet(new String[] {"fullname"} ));

Resources