We have determined that if you have two entities that are related and then you leave the default navigation properties between them (one pointing to the other and back), then saving Entity data is not possible. Only one navigation property can be kept.
For example:
ENTITY:USER
Property.UserId
NavigationProperty.Favorites
_
ENTITY:FAVORITE
Property.FavoriteId
Property.URL
Property.UserFk
NavigationProperty.Users
Does anyone know of an easy way to detect these circular navigation properties? I know one way is to look for them by hand - we're doing that, but we have hundreds of entities in our EDMX and "manual" approach is proving to not be a realiable option.
Thanks.
We have determined that if you have
two entities that are related and then
you leave the default navigation
properties between them (one pointing
to the other and back), then saving
Entity data is not possible. Only one
navigation property can be kept.
You have determined it wrong - saving entities works without any problem. The only scenario where this cause problems is serialization where it can be solved for some serializers with additional metadata.
Related
We have a lots of Entity and we are trying to limit the number of SQL objects generated by CodeFluent Entity. We are using some lightViews but I have the feeling that a lot of generated views are useless.
Is it possible to decide Entity by entity to produce view or not ? (I'm aware of the produceViews option on the SQL producer but we still need some views)
No this is not an option. The produceViews attribute only related to persistent views explicitly defined in your model.
Now : if you are completely in control of what you can use, sure you are not referencing some default generated views in any model attribute, any methods (CFSQL or raw SQL), or partial code, then here some ideas :
You can choose not to use the default generated xx_views.sql :
- do not keep it in sourcecontrol
- provide your own views (the persistent known ones extraceted from the generated file) in a custom post SQL script after_[DefaultNamespace]_views.sql : in it you could for instance delete all existing views, then declare only the ones you want to use. It would be a manual step that can be time consuming if your persistent views are changing a lot between versions. May be a good name convention for persistent views will help this manual report for a good enough solution.
Another more advanced and cleaner idea would be to provide a custom aspect removing the "default" view created for each entity in the meta model before production (see infered meta model and CodeFluent.Model.Entity class), except for entities marked with a custom attribute. This is an idea not guaranted/tested.
Is it possible to define navigation properties between Views in EF with code first? Please, note that I do not need any tool generating any code for me. I would like to know whether or not this can get done and the logic behind this.
Suppose you have a project in which you will only work with views. No data will be created, updated or deleted (at least by you). All you need to do is queries and all you have are views.
Suppose now a second scenario in which you can also have tables, but your purpose is only to visualize data (you will treat them as views). However, there is not always a foreign key referencing the primary key of the parent table in relationships.
My question is: Can I define navigation properties in these scenarios? Or do I have to relay on joins only?
Thanks!
I'm working on this myself. Everything I'm reading indicates you have to manually edit the .edmx files so that the views are considered tables and manually add the nativation properties yourself. Downside is if you resync against the database you have to repeat the process all over again.
Re:
https://social.msdn.microsoft.com/Forums/en-US/dcbdfe52-6ba7-4e75-94aa-51c88b57635c/adding-navigation-property-to-a-view?forum=adodotnetentityframework
Ok so I have my roots defined. Entities inside a root are allowed references to other entities inside the same root, but not outside. There they can only have the identity or the related entity. This is all great.
But, I'm using EF5 and navigation properties are getting in the way. I really want to only define navigation properties where entities are inside the aggregate. But how can I apply some referential integrity where related entities are in different aggregates? Is the only option to add FKs manually using migrations?
And again, but... this is going to cause a bit of a problem because I want to be able to have ReadOnlyRepositories for fetching aggregated data from all over the place. I don't want to get into CQRS as there is too much of a leap there I feel. Am I stuck needing a second bounded context with a new set (or maybe derived set) of entities with extra navigation properties defined? All so i can write queries that pull data from more than one root?
Needing referential integrity usually indicates a deeper issue. Why do you need the entity identifier to exist in both tables? What is being held consistent that way? And why isn't that modeled explicitly? These questions are not as important as the answer to them. Also realize that by just using other technology over the same db schema (and proper indexes) many of your problems could go away. Who knows, you just might be doing CQRS at that point in time.
My iPhone app has a summary page (UITableView) where I would like to show a quick overview and therefore I need to get info from several entities. It was suggested to create an abstract parent entity and have my two entities as children of this one. This do allow me to fetch the two entities using the one fetchedresultscontroller.
This works but I find that I need to filter the return a small bit. Because of the 'hack' above these entities have nothing in common so I need completely separate predicates.so from EntityA I would need "color = blue" and from EntityB "length >= 10". Because the entity I'm actually querying have none of these this doesn't work at all.
Is there a way to do this or what's the best approach here?
Niether the UITableView or the NSFetchedResultsController is designed to deal with more than one entity at a time. Moreover, it seldom makes any sense to try to do so. If you find yourself in such a situation, you probably need to rethink your data model design.
If entities are logically associated with each other then they should be linked by a relationship. If data from any two objects is to be displayed in the same tableviewCell without being gibberish then they must have some logical association and therefore should be linked by a relationship of some kind. To display in the table, you fetch one side of the relationship and then walk the relationship/s to find the other related objects.
If the logical association is strong, it should be defined as a formal relationship in the data model e.g.:
EntityA{
//... some attributes
b<-->B.a
}
EntityB{
//...some attributes
a<-->A.b
}
However, if the relationship is weak or transient, then you should use a fetched property to relate them. The fetched property dynamically searches for other entities based on a preprogrammed fetch.
EntityA{
creationDate:date
someBs--(creationDate=$FETCH_SOURCE.creationDate)-->B
}
EntityB{
creationDate:date
}
A key concept here is that Core Data is providing the entire model layer of your Model-View-Controller design. It is not just a dumb database but an active object graph that models both the data itself and its behavior. Once you have a properly designed data model, problems with the controllers and views resolve themselves automatically.
If i understand correctly, you can use notifications and send a dictionary of required information to the UITableView view controller class.
Does anyone know if it's possible to not use the navigation properties feature of the entity framework for tables linked with a foreign key?
for example, if my client table has an AddressId, I want that AddressId in my model, I don't want it to have a .Address property. But I have thus far been unable to figure out how to do this.
Sure, you can do this. It's just that the designer won't help you very much. Delete the navigation property, and add a scalar property for AddressId. It will work, but you'll have to be careful about hitting Update Model in the designer, as it may try to "fix" things for you. It's worth getting used to editing EDMX; it's not that bad.
In the designer, you can set the navigation properties as having Private getters/setters. While they will still be there, because Entity Framework (by default) does lazy loading, it won't actually retrieve any data from the database at runtime. And they won't respawn the next time you update the model from the database.