I am experimenting with retrieving an ActivityPointer 2 ways:
First way
public Entity GetEntity(NonNullable<string> entityTypeName, Guid entityId)
{
return
_organizationService.Retrieve(
entityTypeName, entityId,
new ColumnSet(true));
}
Second way
public ActivityPointer GetServiceActivity(Guid entityId)
{
return _xrmServiceContext.ActivityPointerSet.FirstOrDefault(x => x.Id == entityId);
}
When passing in the same guid for entityId, why does the first way return a significantly smaller object?
You are trying to compare 2 different objects altogether. The underlying object Entity is of the type Microsoft.Xrm.Sdk.Entity, while the underlying object ActivityPointer is of the type Microsoft.Xrm.Client.CrmEntity.
One of the reason why Microsoft.Xrm.Client.CrmEntity has a bigger footprint is because it contains related entity records metadata, which is lazy loaded when you try to access the related entity property. So, the more related entities, the bigger the object, which in this case an activitypointer does have.
Related
I've been searching for an answer on how to delete ALL records from a table using LINQ method syntax but all answers do it based on an attribute.
I want to delete every single record from the databse.
The table looks like so:
public class Inventory
{
public int InventoryId { get; set; }
public string InventoryName { get; set; }
}
I'm not looking to delete records based on a specific name or id.
I want to delete ALL recods.
LINQ method syntax isn't a must, bt I do prefer it since it's easier to read.
To delete all data from DB table I recommend to use SQL:
Trancate Table <tableName>
Linq is not meant to change the source. There are no LINQ methods to delete or update any element from your input.
The only method to change you input, is to select the (identifiers of the )data that you want to delete in some collection, and then delete the items one by one in a foreach. It might be that your interface with the source collection already has a DeleteRange, in that case you don't have to do the foreach.
Alas you didn't mention what your table was: Is it a System.Data.DataTable? Or maybe an Entity Framework DbSet<...>? Any other commonly used class that represents a Table?
If you table class is a System.Data.DataTable, or implements ICollection, it should have a method Clear.
If your tabls is an entity framework DbSet<...>, then it depends on your Provider (the database management system that you use) whether you can use `Clear'. Usually you need to do the following:
using (var dbContext = new MyDbContext(...))
{
List<...> itemsToDelete = dbContext.MyTable.Where(...).ToList();
dbContext.MyTable.RemoveRange(itemsToDelete);
dbContext.SaveChanges();
}
My team is using Entity Framework 4.3.0 - Code Only with POCO classes as our ORM. Right now we use DBSets of Classes to access our 'tables'
Public Property Customers As DbSet(Of Customers)
But often we are doing soft deletes based on a IsDeleted column in LINQ, and filtering our select statements accordingly:
Dim LiveCustomers =
From C In EM.Customers
Where C.DeleteFlag = False
What I would really like to do is, instead of writing every query to include this filter, create some lower level property (possibly at our inherited DbContext level) that provides the filtered set, while maintaining strong type.
I tried this:
Public Property Customers As DbSet(Of Customer)
Public Property Customers_Live As DbSet(Of Customer)
Get
Return From C In Customers
Where C.DeleteFlag = False
End Get
Set(value As DbSet(Of Customer))
Customers = value
End Set
End Property
However that yielded me this error:
Multiple object sets per type are not supported. The object sets 'Customers' and 'Customers_Live' can both contain instances of type '__.Customer'.
A quick check on google yielded this promising result (How to: Query Objects with Multiple Entity Sets per Type) But after updating my Connection String, I'm still getting the same error.
<add name="EntityManager"
providerName="System.Data.SqlClient"
connectionString="
Data Source=xxxxxx;
Initial Catalog=xxxxxx;
User Id=xxxxxx;
Password=xxxxxx;
MultipleActiveResultSets=True"/>
So my question is, how could I effectively create a LINQ view that allows me to apply filtering, without impacting the upstream usage too drastically?
Change your property like this:
Public Property Customers As DbSet(Of Customer)
Public Property Customers_Live As IQueryable(Of Customer)
Get
Return From C In Customers
Where C.DeleteFlag = False
End Get
End Property
This is slightly different, as you won't have things like Add() or Remove(), but for a view you typically wouldn't expect to have that kind of functionality. If you want to add a new one, or remove one you should use the normal Customers property.
You could have your POCO classes inherit from a new class that has a new method that would do the filtering for you. Add something like this to the new class
--PSEUDO CODE!--
Public Function Filtered() as IEnumerable(Of Out T)
Return (From x In Me Where x.DeleteFlag).ToList()
End Function
and you could call it like:
Dim LiveCustomers =
From C In EM.Customers.Filtered
Or you could create an Interface and do a dependancy injection when you call your linq query. You'll have to google that one :)
A majority of the examples I see now are either using the Code First Approach or using an older version of MVC and the Entity Framework.
Assume I have a movie to update and I get to the Edit View, in the Edit method with the Post verb, what is the proper way to update a Movie? The first Edit Method below gets me to the Edit View with the populated Movie values and the second one is the one I want to use to update, I have tried some things, but nothing updates the data.
public ActionResult Edit(int id)
{
var movie = (from m in _db.Movies1
where m.Id == id
select m).First();
return View(movie);
}
[HttpPost]
public ActionResult Edit(Movie movie)
{
try
{
// TODO: Add update logic here
//What do I need to call to update the entity?
_db.SaveChanges();
return RedirectToAction("Index");
}
catch
{
return View();
}
}
Assuming that _db is derived from ObjectContext you have two options:
Change the state of the entity to Modified:
_db.Movies1.Attach(movie);
_db.ObjectStateManager.ChangeObjectState(movie, EntityState.Modified);
_db.SaveChanges();
This marks all properties of movie as modified and will send an UPDATE statement to the database which includes all column values, no matter if the values really changed or not.
Reload the original entity from the database and apply the changes to it:
var originalMovie = (from m in _db.Movies1
where m.Id == movie.Id
select m).First();
// You actually don't need to assign to a variable.
// Loading the entity into the context is sufficient.
_db.Movies1.ApplyCurrentValues(movie);
_db.SaveChanges();
ApplyCurrentValues will mark only those properties as modified which really did change compared to the original and the UPDATE statement which will be sent to the database only includes the changed column values. So, the UPDATE statement is potentially smaller than in the first example but you have to pay the price to reload the original entity from the database.
Edit
How does the second code example work?
When you run a query using the context (_db) Entity Framework does not only retrieve the entity from the database and assign it to the left side of the query (originalMovie) but it actually stores a second reference internally. You can think of this internal context "cache" as a dictionary of key-value pairs - the key is the entity primary key and the value is the entity itself, the same object as originalMovie refers to.
ApplyCurrentValues(movie) looks up this entity in the context's internal dictionary: It takes the key property value Id of the passed in movie, searches for an entity with that key in the internal dictionary and then copies property by property from the passed in ("detached") movie to the internal ("attached") entity with the same key. EF's change tracking mechanism marks the properties as Modified which were actually different to create later the appropriate UPDATE statement.
Because of this internal reference to the original entity you do not need to hold your own reference: That's the reason why originalEntity is not used in the code. You can in fact remove the assignment to the local variable altogether.
The example would not work if you disable change tracking when you load the original entity - for example by setting _db.Movies1.MergeOption = MergeOption.NoTracking;. The example relies on enabled change tracking (which is the default setting when entities are loaded from the database).
I cannot say which of the two examples has better performance. That might depend on details like size of the entities, number of properties which have been changed, etc.
It's worth to note though that both approaches do not work if related entities are involved (for example movie refers to a category entity) and if the relationship or the related entity itself could have been changed. Setting the state to Modified and using ApplyCurrentValues both affect only scalar and complex properties of movie but not navigation properties.
Your second edit method should look something like this:
[HttpPost]
public ActionResult Edit(int id, FormCollection collection)
{
var movie = (from m in _db.Movies1
where m.Id == id
select m).First();
if (TryUpdateModel(movie))
{
_db.SaveChanges();
return (RedirectToAction("Index"));
}
return View(movie);
}
I have a basic view that returns the same columns as a table (give or take 1 field)
in my DAL code, i am returning a list of MyTableObject, however in some cases, i will call the view to return the same data, but from different sources.
List<MyTableObject> tableObjects = new List<MyTableObject>();
if (case1)
tableObjects = entities.MyTableObjects.Where(criteria).ToList();
else
tableObjects = entities.MyViewObjects.Where(criteria).ToList(); // <-- This will obviously break
return tableObjects;
is there a way to Map view entities to be returned as table entities? (other than having table and view implement the same interface and return that interface) i would like to keep the return type as MyTableObject.
I came across Auto Mapper, but not sure if it would be suitable for this scenario..
Looks like i found a cool solution to this..
Initially I tried to implement interface approach and run into some casting issues (using interfaces alongside my predicate builder), and also with interfaces having to create partial classes for each entity that implement the interface..
the answer.. POCOs.
Iused Poco Template for EF, and than simply edited xxxPocoGenerator.Context.tt to return MyTable object from MyViews collection (one line).
public ObjectSet<Trade> v_Trade {
get { return _v_Trade ?? (_v_Trade = CreateObjectSet<Trade>("Trades")); }
}
nice and easy..
You can write a stored procedure (or CommandText in the model, without creating DB Object) that will simply call "Select * from View". Then create Function Import for this procedure and set the return type to MyTableObject.
I have an Extension method which is supposed to filter a Queryable object (IQueryable) based upon a collection of Ids....
Note that IQueryable is sourced from my database via a LinqToSql request
public static IQueryable<NewsItemSummary> WithID(this IQueryable<NewsItemSummary> qry, IQueryable<Guid> Ids)
{
return from newsItemSummary in qry
where Ids.Contains(newsItemSummary.ID)
select newsItemSummary;
}
If Ids are created from an array or list and passed in as a queryable list, it DOESNT work
For example...
GetNewsItemSummary().WithID(ids.AsQueryable<Guid>())
If Ids is composed form a LinqToSql request, it DOES work!!
This is known issue:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=355026
My Ids collection cannot come from a LinqToSql request...
Note, if I change the function so that it consumes and IList rather than an IQueryable....
public static IQueryable<NewsItemSummary> WithID(this IQueryable<NewsItemSummary> qry, IList<Guid> Ids)
{
return from newsItemSummary in qry
where Ids.Contains(newsItemSummary.ID)
select newsItemSummary;
}
I now get the following exception:
Method 'Boolean Contains(System.Guid)' has no supported translation to SQL.
So... all I want to do is filter my collection of news based upon a list or array of Guids.... Ideas???
This will translate.
public static IQueryable<NewsItemSummary> WithID(
this IQueryable<NewsItemSummary> qry,
List<Guid> Ids
)
{
return from newsItemSummary in qry
where Ids.Contains(newsItemSummary.ID)
select newsItemSummary;
}
)
Translation of the Contains method against local collections was one of the last features added in the development of linq to sql for .net 3.5, so there are some cases that you would expect work that don't - such as translation of IList<T>.
Also, be aware that while LinqToSql will happily translate lists containing a vast number of items (I've seen it do over 50,000 elements), SQL Server will only accept 2,100 parameters for a single query.