Develop Reference

EF6 Code First : Entity with multiple relationships

I am creating a new database using EF code-first which contain the following classes:
Address, Contact, Account, Customer (a sub-class of Account), and SalesOrder.
The Address class is the one giving me problems at the moment, it can have no foreign key because it can be linked to any of the other five classes (with more to come), and each of the other classes can have one or more navigation properties pointing back to it.
The navigation properties should look as follows:
Contact.AddressId?
Contact.Address
Account.AddressId?
Account.Address
Customer.DeliveryAddresses
SalesOrder.InvoiceAddressId
SalesOrder.InvoiceAddress
SalesOrder.DeliveryAddressId?
SalesOrder.DeliveryAddress
It should be possible for these classes to share the same Address record, e.g. an Account has an Address, this can also be linked to a SalesOrder, a different Address, linked to the Customer, could be linked to another SalesOrder. All Addresses linked to Accounts and Customers should be unique, but other classes should be able to share links to these Addresses.
I have tried setting it up with all the possible fluent configurations I can think of, with my DbContext having a DbSet property and without (ultimately I don't think it should have it's own DbSet property, as the Addresses should only be accessible from the various root objects, but if that's the only way to get it to work I'm happy to manage the inserts/deletes myself).
I tried making all the navigation properties nullable (ideally SalesOrder.InvoiceAddressId should not be nullable), and also had to remove the Customer.DeliveryAddresses Many-to-Many mapping at one point because that was confusing the issue.
I get various errors depending on how I have it set up, either Multiplicity conflicts due to non-nullable fields, or Cascade on Delete errors when I have no DbSet property and I try and let EF handle the inserts and deletes.
I also end up with unwanted null rows when I do have a DbSet property set. e.g:
add three Address records to the DbSet (Address(1), Address(2), Address(3),
add two Accounts to the DbSet (Account(1) & Account(2)),
add multiple SalesOrders,
set Account(1).AddressId = 1
set Account(2).AddressId = 2,
set SalesOrder(n).InvoiceAddressId = 1,
set SalesOrder(n).DeliveryAddressId = 3
This will correctly create the Address records, but the related keys will only be set correctly if the various Id foreign-key properties are used, rather than the navigation property, and even if the Id properties are used the foreign keys all look correct, but orphaned records for each SalesOrder (or two per order if both navigation properties are used) end up in my Address table with all their fields bar Id set to NULL.
The only thing I can think of that I haven't tried would be to create multiple sub-classes of Address and use each one with it's related class (e.g. SalesOrderDeliveryAddress), but that doesn't seem ideal. I'd rather not do that unless I have to.
Is what I'm looking for possible to set up in EF, or is there some other way to go about doing it?
Thanks,
David

There are several issues making this confusing. To start with I would switch off the default cascade on delete to get rid of multiple cascade paths and come back to that later.
Then read about adding disconnected trees, foreign keys and navigation properties here: http://msdn.microsoft.com/en-us/magazine/dn166926.aspx
Then I would set up the entities you way you want them and repost a more specific issue. (You have tried lots of stuff so it's hard to work out what happens when here)
Once you've got adding and updating working you can come back and work out where you can put in cascade delete and where it needs to be manual

RavenDB polymorphic Index

I'm working with RavenDB, and I'm trying to do something. I have a base type, Principal, from which two classes are derived: User and ApplicationInstance. In my application, instances of User and ApplicationInstance must be created and stored frequently. The thing is, though, that I need to also be able to query all of the Principal objects stored in the database at once, determine whether a given Principal is a User or an ApplicationInstance, and then query for the entire User or ApplicationInstance object.
How can I do this?

You can define a Multi Map Index that uses as source both the User and ApplicationInstance collections.
If you define your index using C# code (by implementing AbstractMultiMapIndexCreationTask<>), you'll have to call AddMap twice to achieve that (as illustrated in the blog post link above)
If you define the index using Raven Studio, simply click the Add Map button and you'll get a new text area which allows you to define an additional Map.
Note, however, that the output structure of both maps must have the same properties (pretty much as you would do with UNION in SQL).

What are you trying to do? If the end result is to query all Principals, then load the entire User or AppInstance, why not just go straight for querying all Users or all AppInstances?
Raven won't store base classes; it will only store the most derived type (User or AppInstance, in your case). So you'll have a collection of Users and a collection of AppInstances.
If you really need to query both at once, you can use Multi Map indexes. You can also change the entity name and store both in a single Principal collection.
But it's difficult to recommend a solution without knowing what you're trying to do. Explain what you're trying to do and we'll tell you the proper way to get there.

How are relational members from LINQ to SQL DataContext handled when objects are sent via WCF?

Let's say I have a relational database with tables: OrderableCategories and Orderables. They are in a relation of one-to-many with one OrderableCategory attached to multiple Orderables. Therefore, an OrderableCategory instance in LINQ has members: ID, Name and an EntitySet<Orderable> Orderables. While sent via WCF (wsHttpBinding if it matters anyhow), the EntitySet is translated to simple Orderable[]. An Orderable Instance also contains a member called OrderableCategory which is simply an instance of this orderable's category. While sent via WCF, I guess something like this happens: an Orderable instance fills its OrderableCategory instance with fields from this category, but its Orderable[] is also filled with other orderables in this category. These orderables have its OrderableCategory filled with this category again and so on, so that I could theoretically call (for a received orderable o): o.OrderableCategory.Orderables[0].OrderableCategory.Orderables[0]. (...) and so on. I'm only guessing that the server gets into an infinite loop and when message size exceeds the quota, it disconnects and I see an exception of service shutting down. How can I avoid this scenario and have the benefits of relations in my database? I think my suspicions are correct, because when I disabled one of the properties (made it internal in LINQ Class Designer), the data is filled "one-way" only and the Orderable has no longer its OrderableCategory member, it works. But I would like to know if this could be achieved without compromising the property.

This must be handled by marking entities with DataContract attribute and setting its IsReference property to true. This will instruct DataContractSerializer to track references instead of serialize objects as you descirbed.
Linq-To-Sql designer / SqlMetal should do this for you by setting Serialization Mode to Unidirectional.

If you send entities over WCF, nice features like lazy loading go out the window, of course.
You basically need to decide which of the two options you'd like to use:
if you ask for the entity OrderableCategory, you can return just its basic "atomic" properties, e.g. ID, Name and so on. The benefit is smaller size - you're sending back less data
or alternatively: if you ask for the entity OrderableCategory, you can return its basic properties plus you could load a whole list of Orderables that this category contains, and return both at the same time; benefit: you have that data available right away, but on the downside, you'll have to send a lot more data.
Obviously, you cannot really do an infinite eager pre-loading - at some point, you have to stop and leave retrieval of more data to a later WCF service call. Your client would have to ask specifically and explicitly for yet another OrderableCategory if you're interested in that.

Entity Framework Code First POCOs and reasons why / why not setup relationships?

I wasn’t sure how to really word my question and I may change it based on some feedback.
When it is a good idea to have reference relationships (in my POCOs) setup so I can look up a parent record from a child or the reverse? Is it good practice to always have a way to “reverse” lookup an item or collection of items? I know it greatly depends on my application, but I just want to make sure of this before I start molding my application.
So, let’s say I have two tables: States and Countries. States has a relationship with countries (many-to-one) and vice-versa (one-to- many). My class for state would have a property for Country and my Country class would a property for a collection of states. This is pretty standard.
In that example it may make sense to allow a country to lookup the associated states. Can someone think of a time where I may not care about that association so I don’t have the overhead of loading the items for a collection or a single item?

It is more about design decission of your entities. If you are using code first you always need a navigation property on at least one side to create relation in the database. You can start with a simple approach and define property on a side where it make sense and add it to other side only if you need it somewhere.
There are situations where you know that you will never work with child entity without its parent (it leads to theory about aggregation roots whre child entity can't exist without its parent). In such case child doesn't need to have navigation property to parent.
In your scenario do you expect to work with State without Country which it belongs to? If yes it is probable that you would like to know which States a Country contains but in the same time you would probably would like to know which Country a State belongs to so defining navigation property on both sides make sense.

Is it possible to get NHibernate to auto-generate an ID if the entity does not have one, or use the ID of the entity if it already has one?

According to REST philosophy, a PUT operation should (taken from Wikipedia):
PUT http://example.com/resources/142
Update the address member of the collection, or if it doesn't exist, create it.
NHibernate seems to have two ways of dealing with entity IDs:
Auto-generate an ID, regardless of what value the user set.
Use the ID assigned by the user, but lose all auto-generation capabilities.
The problem here with a PUT operation is the part about creating the entity if it doesn't exist. My assumption is that if you PUT a resource that doesn't exist, it will create it with the same ID as specified by the URL (such as 142 if we use the above example). However, NHibernate doesn't allow you to set the ID if it's auto-generated.
So my question is, is there a way to get NHibernate to auto-generate an ID if the entity doesn't have one (or has the default value for the ID type, for example 0 for ints), but also save the entity with the ID that the user set?

Generally its a bad idea to use assigned ids.
The situation that you have is closer to the thing called NaturalId. You should use it I think. You will need to have two different properties, one for databases primary key, and second as a id that is visible to users.