Has anyone implemented a HiLO key generator for the Entity Framework.
Read more about HiLo here:
I recommend that you read http://fabiomaulo.blogspot.com/2009/02/nh210-generators-behavior-explained.html for a detailed explanation of the downsides of choosing identity.
Yes, someone has implemented HiLO for Entity Framework. I haven't tested it myself though:
http://joseoncode.com/2011/03/23/hilo-for-entityframework/
Thanks for the answers
I think I just have to wait :-) The EF is moving in the right direction love the CTP5.
I need to comment on the answer from "Rap". Using random Guid's as indexes can really slow down the performance on the SQL Server because the indexes for each insert becomes fragmented.
This I have learn from the real world, when I started working at a new company that had big problems with performance on there sql servers. moving from guid to bigint solved the problem. and there was no need to reindex all the time.
Unfortunately, EF doesn't have anything very close to the POID generators like NHibernate does, although I hear rumors that similar capabilities will be included in the next release of EF. (What?!? Microsoft co-opting a competitor's good idea? Inconceivable!)
It wouldn't be too tough to handle the Lo part of HiLo ourselves, but the Hi part would be tricky unless we could get EF to cooperate. That would take Microsoft to refactor parts of EF which is probably why nobody has tried to do it and publish it as an open source project on github or codeplex.
In the meantime, what we've used for generating records offline and then syncing at a later time is the globally unique identifier.
var id = Guid.NewGuid();
Then assigning it to the table's id. This can be done in SaveChanges.
I know it isn't as good as HiLo but it's as close as we've come. It still has the advantages of being able to work offline and guarantee valid and unique ids.
IMO Entity framework doesn't have any equivalent to NHibernate's generators. The only feature available in EF is StoreGeneratedPattern which can be set to Identity. StoreGeneratedPattern simply means that DB will assign a key and the key is returned as part of insert operation back to EF context (harder with Guids).
If you want to have some equivalent to NHibernate POID generator you have to override SaveChanges or handle SavingChanges on your ObjectContext. Then you can manually assign ID to all inserted entities from POID algorithm of your choice - but you have to implement the algorithm.
Entity Framework 7 has support: https://channel9.msdn.com/Blogs/Seth-Juarez/Key-Generation-Strategies-in-Entity-Framework-7
public class ExampleContext : BaseContext {
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ForSqlServerUseSequenceHiLo();
}
}
Related
I have a DbSet<Account> Accounts { get; set; } that has a fairly typical Entity Framework Accounts table created from it. It has a couple of references in the OnModelCreating(DbModelBuilder modelBuilder) due to foreign keys in other tables and over 70 references throughout the code where it's used as you might expect (LINQ, Fluent API, etc).
I'd like to source the data that normally would come from the Accounts table from an outside source without having to change any of the other code referencing that DbSet, besides perhaps removing the FKs if necessary.
Ideally it should still function entirely as before, like a normal DbSet, but I need to fetch and provide the data on the fly from another source other than the table.
Working with Entity Framework Core I have seen the concept of an in-memory database used, at least for testing. I don't know if this functionality exists in Entity Framework 6, or if it does if there is any way for me to harness it or use it for only a single table.
In theory I could simply add code that updates/refreshes the data in the in-memory table at just the right times, meanwhile the rest of the tables still exist in the database as before (minus perhaps a few FKs because I'm not sure how that would work in this scenario, but let's assume getting rid of the FKs is a minor issue for now).
Does anyone know if such a thing is possible?
I understand you are trying to get the benefits of EF/LINQ by tricking it into thinking that the data is from a source other than your primary data source. I tend to agree with GertArnold that this would probably be problematic to opt for a solution like you described.
Wouldn't it make sense to instead have another mechanism in place which updates your primary data from the secondary source so that you can be more consistent with EF? Is there some reason why you would not want to have this data replicated/synced with the primary data source for the application?
I'm struggling to get my model's entities to be change tracker proxies rather than utilize snap shot change detection.
My entities are created by the EF designer and have been otherwise unmodified. I followed the steps in Programming Entity Framework: DbContext but my entities never seem to inherit the IEntitiyWithChangeTracker (though they are in fact DynamicProxies).
Can anyone enumerate the steps to make an entity created by the DataBase First EF 6.1 designer into a change tracker proxy? I assume that modification of the classes must be made outside the designer, nothing will be automatic.
So, the answer lies in using the correct Namespace for IEntityWithChangeTracker. In EF6.x if you test with System.Data.Entity.Core.Objects.DataClasses.IEntityWithChangeTracker your entity will return true. Thanks Fred Bao of MSFT
Having run into this issue:
Collection navigation properties may NOT be set
myself for exactly the same reason
and posting this suggestion on uservoice
https://breezejs.uservoice.com/forums/173093-breeze-feature-suggestions/suggestions/3796779-repository-sample-that-serves-view-models-
After seeing the great new compact meta-data feature and reviewing the edmunds sample I am trying to put it all together and come up a solution that allows me to serve DTO's/View models versus full domain objects from a ef-codefirst web api back end and I have come up with two scenerios.
1)Use web api to return the DTO's/create the metadata in JS and use the where parameters to do filtering as required) thus as I understand it the entities can be tracked by breeze. The problem with this is that I will have to override save changes and convert dtos/viewmodels back to EF domain objects and save them. I am not certain that this is either as simple/ or as complex as I can see it being. Basically my proposed algorithm for this is to remove root objects and related children from the change set as DTOs and map them back to Domain objects which can then be added to the context and saved (seems like a lot of work and I am not totaly sure that the order this has to be done in is always knowable)
2) Follow Julie Lermans lead from the Pluralsight Enterprise EF couurse and create the partials directly in EF using code first and just let breeze work as designed. (in the course Julie creates stripped down models of Customer which have attributes placed on them that tells EF to map it to the customer table)
I would love to hear anyones thoughts on this. I am personally leaning towards #2 but I may yet be persuaded to choose #1 if there is a chance of a tool to generate the metadata from my C# clases or if the implementation of SaveChanges can be shown to be manageable and not turn into rewriting half of what EF is supposed to be doing for me)
I was looking into the same issue myself and I ended up going with option 2. For my situation, I felt that I had more control going with option 2 and that I was better able to map my data the way I wanted without feeling that I had more layers than my personal project needed. Julie Lermans "Shrink EF Models with DDD Bounded Contexts" (http://msdn.microsoft.com/en-us/magazine/jj883952.aspx) was a very helpful article for me as well.
I am quite new to entity frame work 4.0 and what I know from my intial analysis is entity framework is nothing but an abstraction of ado.net with its storage model, conceptual schema and the mappping between these two.But one thing I am unclear is while fetching data from database or executing any stored procedure what mechanism its following.
Is it adopting the traditional ado.net approach or is it the concept of linq2sql?
The reason I am asking this question is in our project we are not suppose to use linq for some security reason (I am not sure what this security linkage is but we have not to follow linq relegiously).
So I just wanted to know how entityframework works for performing all its db transaction and whether by any chance it is using linq to sql?
Hope I was able to convey my problem. Please look into this and respond ASAP. I am in a kind of fix :(
Regards
Subrat
No - both Linq-to-SQL and Entity Framework make good use of the LINQ features in C#/VB.NET - but they're both totally separate projects.
Linq-to-SQL was created by the C# team, more or less as a "proof-of-concept" for how to use LINQ with databases.
Entity Framework on the other hand grew out of the database teams (ADO.NET team) at Microsoft and was designed from the ground up as a full-fledged, enterprise-ready system to be the "next big thing" after straight up ADO.NET
Why using LINQ (as a technology) should have any security implications is beyond me.....
Yes - with the Linq-to-SQL approach, your application needs direct access to all underlying tables - read and write. But with EF in version 4, you can do very safe styles of work:
SELECT only from views exposed in the database
handle all the CUD operations (INSERT, UPDATE, DELETE) by wiring up your EF entities to stored procedures
With this, your applications don't need direct table read/write access at all - no different than when manually using SELECT from views and stored procedures for all other operations.
I'm using asp.net mvc, linq2sql, iis7 and sqlserver express 2008.
I get these intermittent server errors, primary key conflicts on insertion. I'm using a different setup on my development computer so I can't debug. After a while they go away. Restarting iis helps. I'm getting the feeling there is cache somewhere that I'm not aware of. Can somebody help me sort out these errors?
Cannot insert duplicate key row in object 'dbo.EnquiryType' with unique index 'IX_EnquiryType'.
Edits regarding Venemos answer
Is it possible that another application is also accessing the same database simultaneously?
Yes there is, but not this particular table and no inserts or updates. There is one other table with which I experience the same problem but it has to do with a different part of the model.
How often an in what context do you create a new DataContext instance?
Only once, using the singleton pattern.
Are the primary keys generated by the database or by the application?
Database.
Which version of ASP.NET MVC and which version of .NET are you using?
RC2 and 3.5.
Two guesses for you:
1) If you've got a singleton DataContext, wouldn't that mean it's shared by all threads?
The MSDN reference for DataContext says an instance is "designed to last for one unit of work" and typically created "at method scope or as a member of short-lived classes".
I'd try moving away from the singleton pattern and creating a new context each time it is needed.
2) When you say your keys are generated by the database, is that through Identity fields, or some kind of "select max + 1" pattern? If not by an identity, then you may have concurrent connections obtaining the same "next" key value. Check your transaction isolation levels.
EDIT - following on from comment
Are you sure that the index violation is on the primary key? Using SQL Server Management Studio, primary keys are normally given a PK_ prefix, and IX_ is used for further indexes. Check the fields which go to make up "IX_EnquiryType" and ensure it's not just a rare logic problem that's causing your problems.
Well, it can be because of many reasons. I'll give you some questions. Please edit your question with the info about these, and it will be much more straightforward for us to help you.
Is it possible that another application is also accessing the same database simultaneously?
This would be the most likely reason. I experienced this, too.
How often an in what context do you create a new DataContext instance?
The best way would be to create a new one per request.
Are the primary keys generated by the database or by the application?
Which version of ASP.NET MVC and which version of .NET are you using?