I am using VS 2013 Express for Web with ADO.NET Entity Data Model.
When updating the entity data model from database using 'refresh' tab option (seems you can only select one item though the heading says select objects plural) the usage seems unclear and I have noticed some issues.
Just two examples:
I changed a stored procedure so it returned the same number of fields but one field was of a slightly different type but the complex type never changed. I realise there can be an impact on client code but this simply did not change the complex type, everything stayed the same. However, removing the relevant elements from the model browser then readding the elments from the database back into the model did exactly what I expected.
I made some significant changes to two or three tables, attributes and one relationship but did bot change the table names. Here again refresh had some very odd results, so I simply created a fresh model.
I am planning some more changes first change specifically I am adding a FK relationship that I forgot.
Is there any way to be sure of what is supported and what is not in terms of refresh.
Also I am concerned that if refresh fails and I so delete the two tables with the relationship, what impact will that have on temporarily orphaned tables and their relationships, and if when I regenerate the two tables their connections with the other tables will still work. I guess it depends how the generated code works underneath.
I want to make these kinds of changes but avoid have to recreate the entire model.
Any advice appreciated.
The most guaranteed way of ensuring you always have the latest version is to select all (Ctrl A) delete, and then re-add everything from the model page.
I know it sounds like a pain but it's guaranteed to work as long as you haven't made any changes to the model from within Visual Studio.
The refresh doesn't always work.
Related
I'm trying to use linq-to-sql, and this is all very new to me.
I am creating objects, that doens't translate to actual tables, in my database. In essence, I have some objects, that get values from 3 different tables, and I select them with stored procedures.
It works great.
However, when I need to submit my changes, I assume SubmitChanges() will not work, and I will need to make my own save functionality.
But how do I see what have actually changed? If I call GetChangeSet() on my datacontext, it says nothing has changed, even though the model has been changed.
Do I need to track the changes manually? If so, are there any tricks or practices I could use?
LinQ to Sql tracks that changes via auto-generated code. You can see it by hitting F12 on linq-to-sql generated object types.
Also, you could study it and make your objects to save changes inside datacontext (which is also a unit of work) the way the generator does.
I have a table that used throughout an app by Entity. I have a view that returns an identical column set, but is actually a union on itself to try to work around some bad normalization (The app is large and partially out of my hands, this part is unavoidable).
Is it possible to have Entity 4 treat a view that is exactly like a table as the same type, so that I can use this view to populate a collection of the same type? This question seems to indicate it is possible in nhibernatem but I can't find anything like it for entity. It would be an extra bonus of the navigation properties could still be used to Include(), but this is not necessary (I can always manually join).
Since EF works on mappings from objects to database entities this is not directly possible. What you need is something like changing the queried database entity dynamically, and AFAIK this is not possible without manually changing the object context.
For sure the EF runtime won't care as long as it can treat the view as if it was completely separate table. The two possible challenges that I forsee are:
Tooling: Our wizard does allow you to select views when doing reverse engineering (i.e. database-first). Definitively if you can use 'code first against an existing database' you can just pretend that the view is just a table, but you won't get any help scripting the database creation or migrations.
Updates: in general you can perform updates for a view setting up store procedure mapping (which is available in the EF Designer from v1 or in Code First starting in EF6). You might also be able to make your view updatable directly or using instead off triggers (see "Updatable Views" here for more details). If I remember correctly the SQL generated by EF to retrieve database generated values (e.g. for identity columns) is not compatible in some cases with instead-off triggers. Yet another alternative is to have your application treat the view as read-only and perform all updates through the actual table, which you would map as a separate entity. Keep in in mind that in-memory entities for the view and the original table will not be kept in sync.
Hope this helps!
I have a legacy database that I'd like to interact with Entity Framework.
The database is highly normalised for storing information about flights. In order to make it easier to work with some of the data, a number of SQL Views have been written to flatten data and to pivot certain multi-table joins into more logical information.
After quickly looking over this I see two problems with using Views in EF.
The Views contains lots and lots of Keys. Some quick googling seems to indicate I will need to manually edit the EDMX file to remove this info.
The Views don't have any relationships to the other table entities. These associations need to be manually added in order to link a View -> Table.
Both of these seem like major pain points when it comes to refreshing the Model from the DB, when teh DBA team make changes.
Is this just something you need to "put up with" when working with EF or are there any suggested patterns/practices to deal with these.
Mixing Table-Entities with View-Entities is ok and largely depends on your requirements.
My experience has been these are things you are going to have to deal with.
When I first started using Entity, I used views a lot because I was told I needed to use them. As I became more familiar with Entity I began to prefer the use of table-entities over view-entities; mainly because I felt I had more control. Views are ok when you are presenting read-only info, or as you described (flattend data, pivots, joins etc.); however, when your requirements change and you now have to add CRUD, you are going to have to use stored procedures or change your model to use table-entites anyway, so you might as well use table-entities from the start.
The Views contains lots and lots of Keys. Some quick googling seems to
indicate I will need to manually edit the EDMX file to remove this
info.
This wasn't ever really a problem for me. You can undo keys of the view-entity in the designer. If your talking about doing this for the view in the storage layer, then yes, you can, to make it work, but as soon as you update your model from the database, you are going to have to do this over again -- I wouldn't recommend doing this. You are better off working with your DBA to adjust the key constraints in the database.
The Views don't have any relationships to the other table entities.
These associations need to be manually added in order to link a View
-> Table.
This was often a problem for me. Sometimes you are able to add keys and create relationships without any problems, but often times you may have to change the keys and/or relationships in the db to make it work -- this depends on your requirements; you may have to deal with this even when using table-entities.
Hope this helps.
I've been in a similar situation as we transitioned into using Entity Framework.
The first step was to start with a blank EF model and add the tables when we created the domain service calls. This at least meant that the model wasn't crazy to start with! Then the plan was to try and not use views as much as possible and move that kind of logic into the domain service, where at least it could be tested, and slowly deprecate the CRUD stored procedures. It's worked fine and there haven't really been any major problems.
In practice there are still some views, mainly used for situations that need to be performant, Fortunately these views can be considered in isolation (for read only grids) and have been left as such in the model with no associations. Adding the keys in would I'm sure be annoying.
Editing the EDMX file is okay, but sometimes on a model refresh these changes can get lost. This has happened to me particularly when EF thinks a table is a view. And yes it's a pain and something that has just been put up with.
Assume that I have a entity data model I generated from my database. I use one of the columns throughout code in many places, but one day I decide that I don't need this anymore, so I remove it from the database and the places in code that reference this property from the entity data model are now broken. Is the only solution to this is to go to each place and fix it or are there any strategies or tools that can assist in scenarios like this?
This question is only practical for applications that haven't been released yet. If an application has been released and this column already exists, it would not be removed or deleted. Existing customers may be depending on that column for data, it may be tied to application logic etc. For compatability reasons, it wouldn't be removed.
If this is pre-production application (pre 1.0 release), any ORM solution should be able to recreate the logical and conceptable model(s) after the physical column in the database has been removed. At that point, there may be some cleanup in the other layers of the application (UI, business, etc) that reference conceptable model in some fashion. For example, the UI may need to be updated to remove the display of that data. That would require some manual effort.
In general, it is better to keep it unless the application is in the early stages of development.
As such, you haven't specified about data in column and need for removing it, so we have to talk in general terms.
If you can remove the column from database and yet has used it in many places at code then probably its computed column - In general, it means you can derive the same information from other data-points. So in your entity model, you should stop mapping the column to the database and rather replicate the logic in the code to compute meaning-full value for the property. Or you can create a view over the table and compute the column at database side and map your entity to the view instead of table.
In case, the column is not computed then removing the column from database means loss of data. And if that is acceptable then it essentially indicates the change in underlying business model where that data point become irrelevant. You have two choices here -
Go for it and change your code for not to use this property - it essentially means that you will adjusting your code for business model/process change that you have to eventually do at some time.
Keep the column in database for some time but have a meaning-full default value. Mark the entity model property obsolete so that it will start giving warning. Take your time to make code changes, ultimate aim is to remove the property usage over a time and then remove the database column.
I was working in L2E with 3 simple tables, whose purposes a fairly straightforward: Users, Users_Roles, Roles.
Users had a 1:many relationship with Users_Roles, referenced on the column UserID (a uniqueidentifier). At the time, Roles had no relation to any tables. I brought all 3 tables into the designer, which reflected the mapping of Users to Users_Roles, while Roles sat all by itself.
Realizing Roles should be mapped to Users_Roles in a many:many relationship, I jumped into management studio. I slapped a relationship from Roles to Users_Roles and saved it. I then jumped back into VS and did the logical the next logical step in my mind - tried to update the Entity model by right-clicking, "Update Model from database". It showed all three tables in its update list. After updating, the visual relationship didn't change. I tried to recompile to see if any changes were made, but received two errors differing only in line numbers:
Error 3 Error 3034: Problem in Mapping Fragments starting at lines 177, 192:
Two entities with possibly different keys are mapped to the
same row. Ensure these two mapping fragments map both ends
of the AssociationSet to the corresponding columns.
C:*\Model1.edmx 178 15 MVCTestApp
Tried to debug the error to no avail. Eventually got frustrated, deleted the model and rebuilt it. The relationships were recognized, the designer was update properly, life was good.
This isn't the first time I've wanted to take the designer outside and bury it, either: a week or so earlier I had the nerve to delete a table, and learned very quickly that deleting a table in the designer only deletes it from the designer; its mappings stay.
So, a few questions:
1) is this behavior limited to VS 2008? I'll have 2010 shortly, and am hoping that the designer functions as expected,
2) are there other tools that can replaced the built-in designer that actually work,
3) is there a way to make update from model actually update - perhaps some trick I'm not aware of besides deleting the entire model, thus losing all my other relationships I've set up manually?
Broken? It's more correct to say that it only recognizes certain DB schema patterns.
The EF supports other patterns, but you need to write the EDMX yourself. If you want the GUI Designer to get everything right for you, you need to follow the patterns it expedcts.
If Users_Roles has only two columns, the UserId and the RoleId and if those are both FKs to their respective tables, and if the two columns together are the PK of the table, then mapping the table will come out right with no work on your part.
Otherwise, you have to study the EDMX format and get the mapping right yourself. As you've discovered, that's trickier.