How do you create a database from an Entity Data Model.
So I created a database using the EDM Designer in VisualStudio 2008, and now I want to generate the SQL Server Schema to create storage in SQL Server.
From what I understand you are not just supposed to use EDM as a "pretty" database designer, in fact EDM does not depend on a specific storage layer. It tries to abstract that part for the developer. There are design schemas (CSDL) and storage schemas (SSDL). Anyway, don't mean to lecture you. ;)
There is EDM Generator, which you use to create models and class, etc.. For a DDL kind of export, I've never done that but what I did was map my EDM to an existing database, which was easier for me to get started.
There is a great tutorial on MSDN, which details step by step instructions on how to go about using an existing database, but also touches the how to start from scratch approach.
http://msdn.microsoft.com/en-us/magazine/cc163286.aspx
The Feature "Generate Database Schema from Model" is scheduled for a future release of Entity Framework. V1 does'nt support schema generatiorn based on EF models.
I believe the other answers implied this, but just to be explicit - use SSMS (or whatever equivlent if you're a brave sole and not using SQL Server provider) to design the DB layout and then suck that into EDM - and then apply application changes as necessary to the model.
I spent about an hour trying to do it your way first (leftover habit from some other Java ORM tools) - I eventually gave up and now do it the 'Right Way' (tm)
Eventually it would be nice (as JRoppert indicated) to have the generate databse schema from model feature - then you could get your DDLs for various DB flavours automagically.
Generating databases from model is a feature planned for vNext of Entity Framework.
Check out this blog post of Entity Framework Design explaining the planned features for database generation from a model.
What you must do right now is either 1) generate the database by hand, or 2) parse the CSDL file and write your own generator. I think option 1) is probably a better option.
Avilable in EF 4:
http://blogs.msdn.com/b/efdesign/archive/2008/09/10/model-first.aspx
Related
I'm pretty new to Entity Framework, and I might be having a hard time "asking the right question" on google. So i'll try here.
First some facts:
I'm working on a project based on the Entity Framework 6.x.
I'm using the Model First approach.
The database is an SQL Server.
My challenge:
Every time my Unit Tests run, I'm dropping creating and seeding a test database using the DropCreateDatabaseAlways<TContext> implementation. The Data Source is an (localdb)\v11.0 instance.
I've gotten to a point where I would like to map an entity to a database view. I can find plenty of material on how easy it is to do the mapping, but what I'm looking for is a way for the view to be applied to my test database upon database creation/initialization?
I'm trying to keep a pure Model First approach. Can anyone help with information on how the views (and Stored Procedures) can be created, when creating the database?
not sure this can be done.
I recently open an issue on codeplex for similar stuff but related to Code First.
The answer was: "edit generated code by hand".
In your case this should be done by inspiring yourself of this post about model first seed data. Instead of seeding, you should send DDL creating view through SQL(...) method as suggested in the answer of cited issue.
BTW: if you think, as I, that such a support should be a good idea, feel free to upvote code first support for view, and/or to create a model first support for view.
I'm putting a front-end together for one of our databases and would like to use NHibernate for it.
Can anyone point out any resources for getting started with Database-first approach? Most tutorials I've seen are for Code/Entity First.
ASP.NET MVC 3 will be my environment, if it matters.
Thanks.
It is all about configuring with NHibernate. As long as Nhibernate is concern, it will not create a database if that is not exists. So you have to configure Nhibernate with the connection string of your existing database in hibernate.cfg.xml(You can also use loquacious api)
There are lots of configuration possibility in NHibernate; Example includes ConfORM, FluentNhibernate, Configuring With Code, XML.
For existing database going with xml is often easy. If you choose xml, you can use tools like myGeneration to generate mappings for you.
As long as you map your object correctly with the existing database nibernate will not complain whether you create your database first or code first. So any intorductory example/application/resource that uses nhibernate as an orm mapper should serve as getting started for you.
Still there are some techniques you can follow to do database first modeling. Here is a link that may help(code example) Effective Techniques for Database-Driven Modeling
Here is the Screen Cast Explaining the techniques
please take a look at this: http://www.devart.com/entitydeveloper/nhibernate-designer.html it is not a freeware.
There is another open source tool which was referred in another question long time back. here is the link: http://www.mygenerationsoftware.com/phpBB2/viewtopic.php?t=1505
btw are you planning to use fluent nhibenrate or just nhibernate?
On a side note: Entity Framework supports a database-first approach with an integrated designer for Visual Studio. This designer produces an XML file (EDMX) that describes the required mappings.
Note: I am not marketing any of these products.
I'm looking into using Microsoft's Entity Framework in an upcoming project which is a point release of an existing product. Our current product supports two DBMS (Oracle and SQL Server), the schema of each is maintained in separate .sql script files.
The entity framework (4.1) looks appealing because it allows various scenarios to be implemented automatically via code generation, reflection, etc. However, as far as I can tell, some of these benefits appear to be mutually exclusive of others.
For example, to support multiple DMBSes, I am inferring that I would need to use a model or code first design, in which case EF would generate the schema for each according to the model (I have seen little to no posts or documentation on this, so I may be wrong). This means that our existing schema would need to be either abandoned (model-first), or mapped (code-first). Additionally, updating the schema would require manual scripts as EF does not appear to support schema upgrades (without wiping out data).
Are model-first and code-first the only viable means of supporting multiple DBMSes in EF? I realize that technically it would be impossible to guarantee that two arbitrary schemae are the same, so I am thinking this is true.
Are there any potential pitfalls of code-first and mapping to multiple DBMS systems? For example, Oracle does not have auto-increment columns; you have to use sequences. How is this mapped in the DbContext? Do I need to create separate maps for each DBMS?
Does EF support any mechanism to upgrade an existing DBMS schema to one of which is representative of the EF model (schema recreation =/= upgrade), or am I limited to doing this manually?
I did come up with one possible way to use database first and support multiple DBMSes, however it is a maintenance nightmare. The idea was to add another layer of abstraction to the two generated data models and create converter classes for each of the EF generated models. This seems like the best way of doing it so that each DBMS could potentially have its own model, yet my code would handle the mapping. But in doing this, what am I really gaining from EF? Maybe query generation, but is that worth it?
Actually both the model-first and the database-first have same constraints. Both these approaches are using an EDMX file which contains SSDL (a description of store = a database layer) part related directly to a single database provider so if you want to have two different database providers you must have two different SSDL parts and keep them in sync. You can use single CSDL (a description of conceptual layer = your model classes) and a single or two MSLs (a description of mapping between SSDL and CSDL - a single file is possible only if tables and columns will have exactly same names in both SSDLs). As I know EDMX file can consists only from single SSDL, CSDL and MSL parts so I expect that the designer has no support for this scenario and you will have to modify second SSDL manually or use two EDMXs = model each change twice.
The code-first approach can make this much more simple but the question is how good is Oracle provider when using the code-first and the database generation. The provider is responsible for correctly interpreting needed features like sequences in case of auto increment columns.
EF itself currently has no support for upgrading existing DB. When using EDMX the process of the database generation is controlled either by T4 template or Workflow so it can be customized and there is already separate feature called Entity Designer Database Generation Power Pack which allow incremental building of the database with the model-first approach. The problem is that this feature is using VS Database tools. I think these tools works only with SQL server. I never like these automated tools so I still think that database upgrade should be controlled manually with help of some tools to get difference script between the current and the last deployed database versions. You should need diff script only when deploying new the new version to a production environment. In a testing and a development environment you can always recreate the whole database.
There should be no abstraction needed when working with two EDMX models. Models must produce the same conceptual layer. In such case you need only a single set of POCO classes which are mapped by conventions (same class name as the entity, same properties with same types and accesibility) so they will work with both models.
Edit:
Based on #Tridus answer I'm just adding that you can create databases first and use fluentAPI from EF 4.1 to map them. Your databases must have exactly the same schema (table names, column names, etc.), they can't use any specific features (I hope sequences will not be the problem because it is just the way how Oracle handles auto increment columns).
This is actually fairly doable with a database first design, but there's some caveats you won't be able to get around easily due to how the databases handle things differently.
Sequences are one (in that they're just ignored by EF entirely). You can fake that in Oracle by putting a trigger on the table that populates it on Insert, but I also found that if you have to update the model later then EF "forgets" that the column is an identity column and it'll try to stick a 0 in it again. I also found it unreliable in Oracle to try and get the new ID if you use a trigger. We just wound up selecting from the sequence and setting the ID on the object before doing the insert because that's how you usually do it in Oracle. You could also use a stored procedure that handles it.
Numbers aren't handled the same way. SQL Server uses number formats that map to Int32, Int64, etc. Oracle's number format is totally different and a full range Int32 in SQL Server is a Number(10,0) in Oracle... which is actually an Int64 in EF because it's bigger then an Int32. I also found that Oracle's EF provider likes to use Decimal a lot even when it doesn't have to, but that's probably just a beta issue.
Stored Procedures in Oracle require some values to be put in app.config/web.config in order to work in EF. I'm not sure if that's going to just be clutter in SQL Server or if it'll cause problems.
Finally, EF Code First is pretty immature and according to the docs doesn't support changing the database structure in this version. I'm not sure if Oracle's provider supports it either (it might, haven't tried it).
Most of this is stuff you can get around, but you're going to need to do some work to hide the differences from the rest of your code and it'll probably take a wrapper layer to do it.
edit - In regards to your #4 - EF 4.1 can generate partial POCO classes. Instead of writing a wrapper around each of the generated models to hide any differences, you can create another partial class code file that won't be regenerated when you update the model, and then add properties/methods that hide the differences. Your app code would just have to be aware to use those instead, and they'd handle the issue (like the number issue I mentioned, you could completely hide it with another property that can do the necessary casting for Oracle).
Is there anyway that I could generate database from one schema to another?
For example, I would like to run my application from oracle to sql server or from sql server to postgresql?
I'm looking for something that's free....
Also I would like to know if there's a schema initializer to go with it
thanks a lot
The best tool I found so far is to use Squirrel's DBCOPY plugin. It really does the job
This doesn't really fall under the "free" category, but if you already have the tools (Microsoft Visual Studio and appropriate .NET providers), it might be a possibility.
The idea is to generate a data model from one database in Visual Studio and then use the Model First functionality to go from the conceptual model to another database. The steps would be something like this:
In a VS2010 application, add a new item to the project: ADO.NET Entity Data Model
Choose your existing database the source for this new model and select the desired tables and click through the wizard.
After the model is created, make sure the conceptual model is visible (.edmx file). In the properties for the model, there should be a DDL Generation Template option. Change this to the desired target type. This is the really iffy part; I don't know how many providers support this, but a quick search seemed to turn up at least one for Postgres.
Right click on the model and choose Generate Database from Model. This should produce the DDL for the new database.
This certainly would not lend itself well to an automated process, but for a one-time process, it might be okay.
When using the Entity Framework there are basically two ways to create your model. You either create the model in SQL server or in Visual Studio EF designer. Those are outlined below.
Start with Database
You first create the model in your SQL server DB then point EF to create the .edmx file for you. By using this approach you can use SQL server management studio to create all of your models and relationships.
Start with Visual Studio EF Designer
This approach is to create the model first in Visual Studio and from that create your database. By doing this it seems like you don't have to be soo concerned with tables and relationships.
Here is what I do and why I do it that way
I start by creating my model using SQL server management studio. I do this because I think its easier to create and modify tables using that tool, also I know exactly what is being created. I create my EF model by pointing it to my existing database. After that I create a Visual Studio Database Project so that my database is scripted into files which I put into version control. When I need to make changes, I change the database and then update my .edmx file as well as my database project.
I was wondering what are the pros and cons to these different approaches and what should be the criteria to decide which to use? Am I doing it wrong? Should I be creating my model first in Visual Studio?
I don't think that there's a 'right' or 'wrong' way to do this, a lot depends on how you deploy your code, where it goes to etc. There is also a third way, which Scott Guthrie blogged about recently:
http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx
As a side note, even if you start with the model designer, I think you always have to think about your tables/relationships, as getting these wrong in the database can cause you big problems further down the line.
I don't think there is a right or wrong way.
At our company we are developing the database changes directly first, apply them to the edmx model for existing models.
For new models, we create the edmx model first, then generate the database. From that point on we usually update the database directly. After we have tested our code internally and it runs correctly, and we know that our SQL database is correct (and of course prior to checking in), we'll then apply the changes to the database project by doing a SQL compare on the database to the database project.
This has worked very well for us.