I've got an Oracle database that I access through Entity Framework and I am seeing a performance hit on selects where I hit tables with CLOB columns in them.
If I break out the query generated by Entity Framework I get similar results when simply calling ExecuteReader using an OracleCommand, but I can improve performance a lot by setting InitialLOBFetchSize to -1 on the OracleCommand.
I would like to do the same for Entity Framework.
How do I tell Entity Framework to set InitialLOBFetchSize to -1?
This is for Entity Framework 4.
I had the same problem few years ago and I ended up using a wrapped OracleConnection, OracleCommand, DbProviderFactory and other ADO.NET classes, and Entity Framework provider so any operation EF does with instances of these classes I was able to inject any functionality in or change the command or connection configuration.
Related
Is there any chance to use ASP.NET Identity with Entity Framework while connecting to an Oracle database?
The challenge seems to be some version conflicts:
The Oracle Data Provider for .NET only targets Entity Framework 5 but not Entity Framework 6.
The NuGet package Microsoft.AspNet.Identity.EntityFramework targets EF6, not EF5.
It's not the code first feature that troubles me. It's getting the connection up and running and reading my user identity data from the Oracle database that bugs me.
Any pointers are much appreciated.
The solution is, of course, in implementing an UserStore class for the IUserStore (and IUserPasswordStore and IUserClaimStore and whatever one needs) interfaces.
Therein, it's just plain EF5 code that queries and updates the ASP.NET Identity tables.
Using this, the UserManager works just fine for accessing all identity data.
I was having trouble finding a path/resource to the query if oracle is supported by Entity framework.
If it does ... which of the following Workflows does it support?
Model First
Database First
Code first(new database)
Code first (Existing database)
Kindly also mention the resource where I can learn Entity framework that has support for oracle.
I am working on a project where performance is a key factor for success. I need to decide whether to use POCO entity generator or not. I might use entityclassgeneration instead of the POCO but I'm not sure if performance may be affected.
Another thing I should consider is the fact of having to work with stored procedures. I'm not sure if using the POCO entity generator template will give me some problems later in the development phase. Specially with the stored procedures.
Any advice would be helpful about using POCO entity generator or entityclassgeneration. By the way, I'm using Entity Framework 5.0 and MySQL database.
When developing with MVC with an ORM
I dont like the idea that the ORM will make changes in my DB.
My application is a data driven application and the DB is the the first thing i created.
Isn't that an overhead to maintain the data scheme both in the model and in the DB?
How do i manage it?
Any ORM that is more suitable to this kind of work method?
I dont like the idea that the ORM will make changes in my DB
ORM don't have to make any changes in your database structure. If you have existing database you can simply use it without requiring any automated changes.
Isn't that an overhead to maintain the data scheme both in the model and in the DB?
How do you want to present your data in MVC? Are you going to use classes representing your data from the database? If yes then you have a reason why ORM exists. ORM maps relational data from database to classes = it loads them for you and persists them for you (= you don't have to deal with database access and SQL). If you are going to use object oriented strongly typed approach then ORM will not be overhead for you.
If you are not going to use such approach you don't have to use MVC. Just use ASP.NET with SQL data sources or ASP.NET dynamic data.
Any ORM that is more suitable to this kind of work method?
You have no special method.
Almost every ORM has some support tools or extensions which allows you creating basic mapping and sometimes also classes from existing database. In EF you will simply add Entity Data model to your project and in wizard selects tables you want in your application.
Sure the last paragraph was simplified. Each ORM has learning curve and its specialties so it will not be so "simple".
For .NET 4 Entity Framework, the tooling let's you go both directions; generate a database from a model and generate a model from a database. These features give you flexibility when implementing your change management protocols. I'm not sure what options are available for NHibernate.
Entity Framework references:
http://msdn.microsoft.com/en-us/library/bb386876.aspx
http://msdn.microsoft.com/en-us/library/bb399249.aspx
http://www.simple-talk.com/dotnet/.net-framework/entity-framework-4460---learn-to-create-databases-from-the-model/
A Stackoverflow comparison of the two:
Deciding between NHibernate vs Entity Framework?
I have used the Entity Framework to start a fairly simple sample project. In the project, I have created a new Entity Data Model from a SQL Server 2000 database. I am able to query the data using LINQ to Entities and display values on the screen.
I have an Oracle database with an extremely similar schema (I am trying to be exact but I do not know all the details of Oracle). I would like my project to be able to run on both the SQL Server and Oracle data stores with minimal effort. I was hoping that I could simply change the configuration string of my Entity Data Model and the Entity Framework would take care of the rest. However, it appears that will not work at seamlessly as I thought.
Has anyone done what I am trying to do? Again, I am trying to write an application that can query (and update) data from a SQL Server or Oracle database with minimal effort using the Entity Framework. The secondary goal is to not have to re-compile the application when switching back and forth between data stores. If I have to "Update Model from Database" that might be ok because I wouldn't have to recompile, but I'd prefer not to have to go this route. Does anyone know of any steps that might be necessary?
What is generally understood under the term "Persistence Ignorance" is that your entity classes are not being flooded with framework dependencies (important for N-tier scenarios). This is not the case right now, as entity classes must implement certain EF interfaces ("IPOCO"), as opposed to plain old CLR objects. As another poster has mentioned, there is a solution called Persistence Ignorance (POCO) Adapter for Entity Framework V1 for that, and EF V2 will support POCO out of the box.
But I think what you really had in mind was database independence. With one big configuration XML that includes storage model, conceptual model and the mapping between those two from which a typed ObjectContext will be generated at designtime, I also find it hard to image how to transparently support two databases.
What probably looks more promising is applying a database-independent ADO.NET provider like the one from DataDirect. DataDirect has also announced EF support for Q3/2008.
http://blogs.msdn.com/jkowalski/archive/2008/09/09/persistence-ignorance-poco-adapter-for-entity-framework-v1.aspx
The main problem is that the entity framework was not designed with persistence ignorance in mind. I would honestly look at using something other than entity framework.