This project has moved. For the latest updates, please go here.

How to work with multiple EntityContainers?

Dec 11, 2013 at 11:43 AM
Edited Dec 11, 2013 at 11:44 AM
I am trying to use Effort in a database first approach, where a single catalog contains multiple schema's which have been split into multiple metadata files. (Dal.A and B) I am using the CSV export to fill my initial database because I need a lot of existing configuration data.

So, I have a connection string which is build up as follows:
<connectionStrings>
  <add name="MyEntities" connectionString="metadata:res://*/Dal.A.csdl|res://*/Dal.A.ssdl|res://*/Dal.A.msl|res://*/B.csdl|res://*/B.ssdl|res://*/B.msl ... // Rest of stuff here
</connectionStrings>
When creating the context however, only the first EntityContainer is used to create a schema. This means that, as long as I'm testing the objects within the Dal.A schema everything works fine, but when I touch an object in the B schema, everything blows up.

I started looking into the Effort source code and came upon the following. When a new DbSchemaKey is created, the following code is executed:
 EntityContainer entityContainer = 
                storeItemCollection.GetItems<EntityContainer>().FirstOrDefault();
So it's effectively taking the first EntityContainer in the collection, where I have 2, therefore creating only one schema.

Does Effort support multiple EntityContainers, should I do something special in my setup or is there a workaround for this?
Coordinator
Dec 20, 2013 at 2:02 PM
Hello,

Thank you for reporting this issue.

It might be a viable solution to merge the metadata of multiple EntityContainers.

However I am curious about the possible scenarios. For instance, is it possible that two EntityContainers have common storage schema (same table in more EntityContainers)? Same table in more EntityContainers but different columns?
Dec 20, 2013 at 2:21 PM
Hello,

In our situation, each EntityContainer maps to exactly 1 schema. A table with the same name might occur in multiple schema's, but until now me managed to avoid this.

I'll try to give a more practical example of what we try to do.

Imagine a car dealership. The database contains information about customers, car configurations and car orders placed by customers. So, to keep things organized, this can be split up into three schema's within a single database instance:
  • customer: Contains all tables which relate to customer accounts, addresses, ...
  • configuration: Contains all tables which relate to car configurations and car options. (What's possible on which make and model.)
  • orders: Contains all actual orders placed by customers.
Code-wise the same setup has been created: three DAL projects, each representing a single schema.

As long as I test within a single schema, Effort works fine, but when I'd place an order, thus touching more than one schema, Effort fails.
Coordinator
Apr 6, 2014 at 10:51 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Apr 6, 2014 at 10:53 PM
Sorry, somehow I completely forgot about this one. I created a workitem based on your description.