I would like to ask the Entity Framework Core team what their ambition is for the scope/complexity of query translation compared to EF6.
I've used EF6 extensively and I know that if you can express it in LINQ and don't use any untranslatable functions, EF can probably translate the query correctly.
Will Entity Framework's translation be eventually as good as that, or is that something that is considered secondary, like the lazy loading feature.
If so, about what is the team eventually aiming at compare to EF6?
There's a ticket discussing GroupBy that appears to indicate they deem grouping an advanced type of query, but compared to what EF6 can translate, a normal group-by is pretty average.
(I'm asking here as the EF Core team says on it's site it is monitoring SO for questions.)
We took a very different approach in EF Core. Every LINQ query should work--even if you use untranslatable functions. We do this by translating the parts of the query we can into SQL and processing the rest on the client after the results are returned by the server. As EF Core evolves, we'll translate more and more of the query into SQL (e.g. GROUP BY) which can make it more efficient.
In theory, our goal is to translate everything that the store supports. In some cases however (especially on NoSQL stores) there simply is no translation for a LINQ operator, and we feel it's better to be functional and inefficient than to throw.
If you want to ensure your whole query is translated, you can disable client evaluation. This will cause it to throw like EF6.
Related
Is Entity Framework faster than ado.net for Queries?
My test shows that ado.net is faster than Entity Framework in querying.Why?
ADO.Net is used by EF under the scenes. This means that overall EF is always going to be slower than ADO.Net (assuming they both are generating similar SQL statements)
However I have observed an interesting performance characteristic with EF5 vs ADO.Net and a low number of rows (either queried or inserted). EF5 appears to be consistently faster than ADO.net for under 10 items. I imagine this is due to an optimisation at connection setup time however I haven't yet tracked down what this is.
My results around this and a little more explanation is avaliable here
If anyone has any more information around why EF5 appears so fast on small datasets I would love to hear.
NOTE in this post I actually don't show the raw ADO.net results but they are very similar to the dapper results. I actually wanted to answer this specific question before posting the ADO.Net results :)
SQL Server 2012 introduces a more efficient mechanism for paging using FETCH and OFFSET which could have a big impact on performance of apps which use a lot of paging. Does Entity Framework 5 support this?
So if Im using EF to page using Take + Skip will the LINQ queries be translated into the new 2012 TSQL if EF is targeting SQL Server 2012?
As #Ladislav said, EF 5 doesn't support OFFSET & FETCH. With that said, I wanted to add a bit of perspective. I don't think it should matter much.
When you buy into an ORM like Entity Framework, you're out sourcing your query generation (for perfectly valid reasons). Whether EF uses the 'older' CTE style query with Row_Number() or the newer Fetch / Offset is an implementation detail. Microsoft could update the EF code at any point and change the query generation to use one or the other.
If you want control over the query generation, you either:
Use EF's 'stored procedure mapping' ability
Use stored procedures directly with EF (something I do quite often)
write the ADO/SQL yourself, or
use a more limited micro-orm like massive/PetaPoco
So does it matter?
Well, to a developer writing queries the new syntax is going to be a welcome relief. On the other hand, it doesn't appear that there is a real performance difference between the old CTE method and the new syntax. So from EF's perspective -- not really. We incur a significant overhead using EF, the method of paging probably won't be your break point.
EF 5 doesn't support this feature - actually I think none of SQL Serve 2012 features is available in EF. You can vote for this feature on Data UserVoice to move it up in ADO.NET team product backlog.
I have recently started getting familiarized with NoSQL (HBase). I am definitely a noob.
I was investigating about ORMs and high level clients which can be used on HBase and came across a few.
Some ORM libraries like Kundera are providing SQL like data query functionality. I am finding this a little counter intuitive.
Can any one help me understand why we would again need SQL like querying if the whole objective was to move away from it?
Also can anyone comment on your experiences with ORMs for HBase? I looked at a few of them from http://wiki.apache.org/hadoop/SupportingProjects and started looking at Kundera.
Another related question - Does data query with Kundera run map reduce jobs internally?
kundera or Spring data might provide user friendly ORM layer over NoSQL databases, but the underlying entity model still has to be NoSQL friendly. This means that NoSQL users should not blindly follow RDBMS modeling strategies but design ORM entities in such a way so that all NoSQL capabilities can be used.
As a thumb rule, the kundera ORM entities should be designed using query-first strategy where first the queries need to defined so as to create primary keys and also ensuring that relationship model is used as minimal as possible. Querying on random columns and full scans should be avoided and so data might have to be replicated across entities for reducing multiple entity look ups. Also, transactions management needs to be planned. FYI, kundera does not support transactions(beyond single row TX supported by Hbase/Cassandra).
Reason for using Kundera:
1) If looking for SQL like support over HBase. As it is build on top of HBase native API, so it simply transforms these SQL queries in to corresponding GET or PUT method calls.
2) Currently it support HBase-0.20.6 only. Kundera-2.0.6 will enable support for HBase 0-90.x versions.
3) Kundera does not do sometihng out of the box to provide map reduce over SQL like queries. However support for such thing will be provided in Kundera-2.0.6 by enabling support for Hive native queries only!
It is totally JPA compliant, so no need to learn something new. It simply hides complexity at developer level with very minimal effort.
SQL like querying is for developement ease, quick developement, less error prone and reusability ofcourse!
-Vivek
What is faster - ADO.NET or ADO.NET Entity Framework?
Nothing is faster than an ADO.NET datareader.
Entity framework also uses this in "the basement".
However entitity framework helps you to map from database to objects..
With ADO.NET you have to do that yourself.
It depends on how you program it how fast it is..
When you use ADO.NET datatables as "objects". They are a bit slower and memory hungry than plain objects..
As Julian de Wit says nothing is faster than ADO.NET DataReaders.
ADO.NET Entity Framework is a wrapper to the old ADO.NET.
It is pure Provider independent, ORM and EDL System.
It gives us a lot of benefits that we have had to hand craft or "copy & paste" in the past.
Another benefit that comes with it is that is completely Provider independent.
Even if you like the old ADO.NET mechanism or you are a dinosaur like me(:P) you can use the Entity Framework using the EntityClient like SqlClient, MySqlClient and use the power of Entity-Sql witch is provider independent.
I Know that with ADO.NET you can write a data access Layer and the DataReaders etc can be "independent" but you have steal have Queries that are provider specific.
On the other hand,in an enterprise application you may never want to change the data provider.
But as the technology grows, always new needs arise and you may want have to alter the database schema.
When it happens with the old ADO.NET Framework we have to refactor alot of code which is less than maintainable, no matter how we reuse the code.
The performance will be affected but with all these cache technologies out there we can overcome this.
As i always say, "The C is fast, the Assembly even more...but we use C#/VB.NET/Java"
Using EF we can use LINQ to read data which is rather simple (especially using fluent calls), but we have less control unless we write eSQL on our own.
Is writing eSQL actually data store independent code?
So if we decide to change data store, can the same statements still be used?
Does writing eSQL strings in your code pose any serious security threats similar to writing TSQL statements as plain strings in C# code? That's why SPs are recommended. Could we still move eSQL scripts outside of code and use some other technique to make them a bit more secure?
ESQL is database independent in general, so it can be used like LINQ to Entities.
But please be aware that it has more serious limitations. It does not have DML, DDL, and DB-specific abilities.
The main ESQL disadvantage is that even simple query containing a couple of lines can be translated into monstrous SQL query for a particular DBMS, so one should check the generated SQL to be appropriate and analyze if it is optimal.
ESQL will not be executed directly on a database, it will be translated to SQL.
EF Security discussion is usually started from the connection string proptection, then model security is discussed, and only after that query protection is analyzed. It's up to the developer to decide if the peculiar query should be protected.