I'm running an EF statement where I need to calculate de deductibles. After long trying, I can't seem to add a custom function in a .Select() statement. Instead I'm trying to add the values after my .Select() statement.
The problem here is, in my CalculateDeductibles() I can't seem to add any values to item.Deductibles.
The GetDeductibles(item.RequestId) is a rather heavy funtion that does several extra queries, so I'm trying to prevent to convert my IQueryable to an IList object.
So there are actually 2 questions:
Can I have the GetDeductibles() function directly in my .Select() statement?
Can I somehow (with keeping an eye on performance) add the value after I did my .Select()
Code:
public IQueryable<ReinsuranceSlip> GetReinsuranceSlipsOverview(int userId, int companyId, string owner, string ownerCompany)
{
IQueryable<ReinsuranceSlip> model = null;
model = _context.Request
.Where(w => w.RequestGroup.ProgramData.MCContactId == userId)
.Select(x => new ReinsuranceSlip()
{
Id = x.Id,
RequestId = x.Id,
LocalPolicyNumber = x.LocalPolicyNumber,
BusinessLine = x.RequestGroup.ProgramData.BusinessLine.DisplayName,
BusinessLineId = x.RequestGroup.ProgramData.BusinessLine.Id,
ParentBroker = x.RequestGroup.ProgramData.Broker.Name,
LocalBroker = x.Broker.Name,
InceptionDate = x.InceptionDate,
RenewDate = x.RenewDate,
//Deductibles = CalculateDeductibles(x)
});
CalculateDeductibles(model);
return model;
}
private void CalculateDeductibles(IQueryable<ReinsuranceSlip> model)
{
//model.ForEach(m => m.Deductibles = GetDeductibles(m.RequestId));
foreach (var item in model)
{
item.Deductibles = GetDeductibles(item.RequestId);
}
}
Updated and Sorry for the first version of this answer. I didn't quite understand.
Answer 1: IQueryable is using to creating a complete SQL statement to call in SQL Server. So If you want to use IQueryable, your methods need to generate statements and return it. Your GetDetuctibles method get request Id argument but your queryable model object didn't collect any data from DB yet, and it didn't know x.Id value. Even more, your GetCarearDetuctiples get an argument so and with that argument generates a queryable object and after some calculations, it returns decimal. I mean yes you can use your methods in select statement but it's really complicated. You can use AsExpendable() LINQ method and re-write your methods return type Expression or Iqueryable.
For detailed info you should check. This:
Entity Navigation Property IQueryable cannot be translated into a store expression and this: http://www.albahari.com/nutshell/predicatebuilder.aspx
And you also should check this article to understand IQueryable interface: https://samueleresca.net/2015/03/the-difference-between-iqueryable-and-ienumerable/
Answer 2: You can use the IEnumerable interface instead IQueryable interface to achieve this. It will be easy to use in this case. You can make performance tests and improve your methods by time.
But if I were you, I'd consider using Stored Procedures for performance gain.
You'll have to understand the differences between an IEnumerable and an IQueryable.
An IEnumerable object holds everything to enumerate over the elements in the sequence that this object represents. You can ask for the first element, and once you've got it, you can repeatedly ask for the next element until there is no more next element.
An IQueryable works differently. An IQueryable holds an Expression and a Provider. The Expression is a generic description of what data should be selected. The Provider knows who has to execute the query (usually a database), and it knows how to translate the Expression into a format that the Provider understands.
There are two types of LINQ functions: the ones that return IQueryable<TResult> and the ones that return TResult. Functions form the first type do not execute the query, they will only change the expression. They use deferred execution. Functions of the second group will execute the query.
When the query must be executed, the Provider takes the Expression and tries to translate it into the format that the process that executes the query understand. If this process is a relational database management system this will usually be SQL.
This translation is the reason that you can't add your own functionality: the Expression must be translatable to SQL, and the only thing that your functions may do is call functions that will change the Expression to something that can be translated into SQL.
In fact, even entity framework does not support all LINQ functionalities. There is a list of Supported and Unsupported LINQ methods
Back to your questions
Can I have GetDeductibles directly in my query?
No you can't, unless you can make it thus simple that it will only change the Expression using only supporte LINQ methods. You'll have to write this in the format of an extension function. See extension methods demystified
Your GetDeductibles should have an IQueryable<TSource> as input, and return an IQueryable<TResult> as output:
static class QueryableExtensions
{
public static IQueryable<TResult> ToDeductibles<TSource, TResult, ...>(
this IQueryable<TSource> source,
... other input parameters, keySelectors, resultSelectors, etc)
{
IQueryable<TResult> result = source... // use only supported LINQ methods
return result;
}
}
If you really need to call other local functions, consider calling AsEnumerable just before calling the local functions. The advantage above ToList is that smart IQueryable providers, like the one in Entity Framework will not fetch all items but the items per page. So if you only need a few ones, you won't have transported all data to your local process. Make sure you throw away all data you don't need anymore before calling AsEnumerable, thus limiting the amount of transported data.
Can I somehow add the value after I did my .Select()
LINQ is meant to query data, not to change it. Before you can change the data you'll have to materialize it before changing it. In case of a database query, this means that you have a copy of the archived data, not the original. So if you make changes, you'll change the copies, not the originals.
When using entity framework, you'll have to fetch every item that you want to update / remove. Make sure you do not select values, but select the original items.
NOT:
var schoolToUpdate = schoolDbContext.Schools.Where(schoolId = 10)
.Select(school = new
{
... // you get a copy of the values: fast, but not suitable for updates
})
.FirstOrDefault();
BUT:
School schoolToUpdate = schoolDbContext.Schools.Where(schoolId = 10)
.FirstOrDefault()
Now your DbContext has the original School in its ChangeTracker. If you change the SchoolToUpdate, and call SaveChanges, your SchoolToUpdate is compared with the original School, to check if the School must be updated.
If you want, you can bypass this mechanism, by Attaching a new School directly to the ChangeTracker, or call a Stored procedure.
Related
The Goal
I'm trying to compare primary keys of two generic types in ADO.NET's LINQ to Entities. The trick is, I can't explicitly compare the properties in the LINQ query because I'm using generic types. Thus, I have to dynamically retrieve the value of the property from both objects in order to compare them.
While I can manually loop through each row in the DB on the application side (my current production approach), I'd still prefer to retrieve direct from the DB using LINQ. It would just keep things simpler I suppose.
The Problem
When trying to use a custom helper, or anything that isn't directly related to the entity itself, the LINQ query fails as not being supported. It is my understanding that when using 'LINQ to Entities', the actual LINQ query is executed using SQL. Being that as it is, I'm extremely limited on how I can handle the conditionals.
Disclamer
This in NOT me asking how to use methods in a LINQ query. Most of the stuff I'm outlining right now will more or less serve for any future visitors who have the same question/issue.
I'm aware that it's not possible to handle this the way I'm attempting. My question is whether or not there is a creative way to handle LINQ to Entities queries using generic types. I'm sure the answer will be 'it's not possible', but I'd like to get some more expert knowledge on the topic. Perhaps somebody who has attempted this before.
Exception
System.NotSupportedException: 'LINQ to Entities does not recognize the method
'Boolean CompareKeys[MyEntityType](System.Collections.Generic.List`1[System.String],
MyApp.DB.MyEntityType, MyApp.DB.MyEntityType)' method,
and this method cannot be translated into a store expression.'
Action
private static void MergeEntityListToDB<T>(List<T> list)
{
var primaryKeys = new List<string>() { "MyEntityTypeID" };
foreach (var row in list)
{
T ExistingRecord = dbRows
.Where(x => CompareKeys(primaryKeys, row, x)).FirstOrDefault();
// Remaining Logic
}
}
Helper
private static bool CompareKeys<T>(List<string> PKs, T obj1, T obj2)
{
foreach (var key in PKs)
{
var val1 = obj1.GetType().GetProperty(key).GetValue(obj1, null).ToString();
var val2 = obj2.GetType().GetProperty(key).GetValue(obj2, null).ToString();
if (val1 != val2)
return false;
}
return true;
}
I think you need to combine LINQ Dynamic Query and possibly LINQKit to achieve your goals. EF (and LINQ to SQL) can't translate reflection to SQL to query a database.
Ideally, I would like to have:
public user Update(User dto) {
var user = userRepository.GetUserById(dto.Id);
var mergedFields = Merge(user, dto); //my dream function
userRepository.UpdateOnly(user, mergedFields)
.Where(u => u.Id == user.Id); //OrmLite UpdateOnly func
return user;
}
Where Merge is my deam function that returns a Linq Expression:
Expression<Func<T, TKey>> Merge(T target, T source)
So, Merge knows what was updated from T source to T target. Update the values of these properties in target, and return these updated properties as Linq Expression for OrmLite UpdateOnly to use.
However, I am pulling my hair and I can't figure out how to write this Merge function. Please throw me some help!
Thank you!
Ref: ServiceStack OrmLite is a light weight ORM. It's UpdateOnly function takes a Linq Expression like this:
.UpdateOnly(new User {FirstName="admin", LastName="my", OtherStuff="etc..."},
u => {u.FirstName, u.LastName}).Where(u => u.Id == 123);
While I can see what you are trying to do, there as already a built in mechanism for achieving partial updates without having to build a Linq Expression of the changed values.
I think OrmLite's UpdateNonDefaults is better suited to your task.
Your Update action should only be receiving changes to your existing record in the DTO, not a full object. So doing this, should be sufficient:
db.UpdateNonDefaults(dto, u => u.Id == 123);
Results in SQL:
UPDATE "User" SET "FirstName" = 'admin', "LastName" = 'my' WHERE ("UserId" = 123);
If your update request where to contain a full object, the database would simply overwrite all the existing values with the same values, but this action shouldn't cost anymore than the processing time to lookup the entire existing object, make comparisons to determine changes using reflection, build a Linq Expression and run an UpdateOnly query.
If you were dead set on checking for changed fields against the original then you could do it without the complexity of the Linq Expression. Your Merge function could do this (PseudoCode):
public T Merge(T target, T source)
{
Create a new default object for the return. i.e. var result = default(T);
Reflect your T target public properties:
foreach(var property in target.GetType().GetPublicProperties()){
With each reflected property:
Determine whether the value changed using an EqualityComparer:
if(!EqualityComparer<FieldType>.Default.Equals(targetField, sourceField))
Set the value on the result object if the value is different.
Return the result object. It will only have the changes.
Now using UpdateNonDefaults with the result will ensure only the changes are included in the update SQL.
Is it worthwhile to do check of the changed fields? You should perhaps run some benchmarks. Remember that checking involves:
Querying the database for the entire existing record.
Reflecting properties on your target and source object.
Making comparisons of values.
Building a Linq Expression or new Object to keep track of what's changed.
Running the update function.
If you get stuck determining the changes on your objects, the answers in this question may help.
I hope this helps.
I'm trying to do the following:
var query =
(from a in session.Query<A>()
where a.BasicSearch(searchString) == true
select a);
But it keeps giving me this exception "System.NotSupportedException"!
Any idea how to solve this?
It is not possible to use user-defined functions in a LINQ query. The NHibernate linq provider does not 'know' how to translate your function into SQL.
LINQ to NHibernate works by inspecting the LINQ expression that you provide at runtime, and translating what it finds in this expression tree into a regular SQL expression. Here's a good article to get some background on expression trees: http://blogs.msdn.com/b/charlie/archive/2008/01/31/expression-tree-basics.aspx
You CAN reuse predicates like this in another way however, using the techniques discussed here. (I'm not sure if this works with NHibernate however.) IF it works it would look something like this:
// this could be a static method on class A
public static Expression<Func<A, bool>> BasicSearch(string criteria)
{
// this is just an example, of course
// NHibernate Linq will translate this to something like
// 'WHERE a.MyProperty LIKE '%#criteria%'
return a => criteria.Contains(a.MyProperty);
}
Usage:
from a in Session.Query<A>().Where(A.BasicSearch(criteria))
UPDATE: apparently there will be issues with NHibernate. See this blog post for a version that ought to work.
It is possible to call your own and SQL functions, but you have to make a wrapper for them so that NHibernate knows how to translate the C# to SQL.
Here's an example where I write an extension method to get access to SQL Server's NEWID() function. You would use the same techniques to get access to any other function on your database server, built-in or user-defined.
Some examples to extend NHibernate LINQ:
http://fabiomaulo.blogspot.se/2010/07/nhibernate-linq-provider-extension.html
https://nhibernate.jira.com/browse/NH-3301
Declare a BasicSearch extension method. Supposing your udf is on dbo:
using NHibernate.Linq;
...
public static class CustomLinqExtensions
{
[LinqExtensionMethod("dbo.BasicSearch")]
public static bool BasicSearch(this string searchField, string pattern)
{
// No need to implement it in .Net, unless you wish to call it
// outside IQueryable context too.
throw new NotImplementedException("This call should be translated " +
"to SQL and run db side, but it has been run with .Net runtime");
}
}
Then use it on your entities:
session.Query<A>()
.Where(a => a.SomeStringProperty.BasicSearch("yourPattern") == true);
Beware, trying to use it without referencing an entity in its usage will cause it to get evaluated with .Net runtime instead of getting it translated to SQL.
Adapt this BasicSearch example to whatever input types it has to handle. Your question was calling it directly on the entity, which does not allow your readers to know on how many columns and with which types it need to run.
1) I wish to clarify some doubts on collections.
SampleDBDataContext PersonDB = new SampleDBDataContext("");
Table<Person> p=PersonDB.GetTable<Person>();
IEnumerable<Person> per = PersonDB.GetTable<Person>();
IQueryable<Person> qry = PersonDB.Persons.Select(c => c);
what are the differences between using Table<Person>,IEnumerable<Person>,IQueryable<Person>.Any specific need to choose the particular one?
2) For Adding records Add() method not appears in my IDE,(i.e) PersonDB.Persons.Add().
What is the problem here?
1.
IEnumerable<> is an interface that
applies to any collection whose
members can be enumerated or iterated
over.
IQueryable<> is a LINQ interface
that applies to any collection whose
members can be lazily queried.
(queried without materializing the
result set until its members are
accessed)
Table<> is a class that I've
not used before but "represents a
table for a particular type in the
underlying database."
Which one you choose depends on what your needs are, but IEnumerable<> is the most general, so I would use that in my type declarations if it's sufficient.
2.
To insert a person use InsertOnSubmit():
Person person = new Person() { ... };
PersonDB.Persons.InsertOnSubmit(person);
PersonDB.SubmitChanges();
Table(T) is the class that LINQ to SQL uses for query results from a table; it is also used for properties of the data context, so that you can use the data context properties in your queries. So the code in your post is duplicating some code that LINQ is already doing for you. PersonDB.Persons should always be sufficient for querying persons.
For results, you will likely want a collection, so while IEnumerable and IQueryable are fine, you can also consider using a list:
List<Persons> pers = PersonDB.Persons.Where(p => p.name == aName).ToList();
Note that this is an immediate execution, not a lazy (deferred) execution. ToList() forces immediate query execution.
Table<> is well, a table. It can return IQueryable results and can perform inserts/other database specific operations. It is linked to a DataContext.
IQueryable<> is a list that is well, not a list. Basically IQueryable doesn't actually load any data until you actually request it (late execution). As a result you can perform multiple operations before the whole thing is sent to the database. Think of IQueryable<> as an SQL statement in progress, rather then the actual results.
IEnumerable<> is just a standard interface for any list of objects that can be enumerated. When an IQueryable actually executes, you get an IEnumerable set to go through.
Add appears for indvidual instances - for example Person.Add(). For raw tables you should use the Insert* methods.
Class Customer has the following method, which returns an IQueryable with the linq query to get the active sales for a customer:
public IQueryable<SalesHeader> QueryCurrentSales()
{
// this.SalesHeaders is an association defined in the DBML between
// the Customer and SalesHeader tables (SalesHeader.CustomerId <-> Customer.Id).
return this.SalesHeaders
.Where(sh => sh.Status == 1).AsQueryable();
}
The idea is to centralise the query definition in a single point, so that later we can get the SalesHeader rows, do a count, paginate using the PaginatedList class (from NerdsDinner), and add further Where conditions when searching Sales within active SalesHeaders.
However, after running the SQL Sever profiler, I've discovered that doing the following, gets all the rows and then does the Count in memory.
// cust is an object of type Customer.
int rows = cust.QueryCurrentSales().count();
I guess that the problem lies in the fact that we have used the AsQueryable() method, but I don't know what would be the correct way to accomplish what we intended.
You haven't shown what SalesHeaders is. The fact that you feel you need to do AsQueryable suggests that it's returning an IEnumerable<T> rather than an IQueryable<T>... which is probably the problem. If you could show SalesHeaders, we may be able to help.
It's possible that instead of using AsQueryable you may be able to just cast to IQueryable<SalesHaeder> if the SalesHeaders property is returning an expression which could actually be returned as IQueryable<SalesHeaders> in the first place - but in that case I'd suggest changing the property type instead.
EDIT: Okay, if it's an entity set then that's probably tricky to fix directly.
I know it's ugly, but how about something like:
public IQueryable<SalesHeader> QueryCurrentSales()
{
// You *may* be able to get away with this in the query; I'm not sure
// what LINQ to SQL would do with it.
int id = this.Id;
return context.SalesHeaders
.Where(sh => sh.Status == 1 && sh.CustomerId == id);
}
Here I'm assuming you have some way of getting to the data context in question - I can't remember offhand whether there's an easy way of doing this in LINQ to SQL, but I'd expect so.
This works right. Doing count() on SQL Server.
// cust is an object of type Customer.
int rows = cust.QueryCurrentSales().AsQueryable<SalesHeaders>().count();