I am about to use linqtosql in my first asp.net mvc application.
I have come up with a database schema. But the problem is that I may change few of the tables in future. So keeping the model classes in sync with database will be a issue.
I got this link which states the similar situation,
keep LinqToSQL sync with the database
My question is, has any body used the third party tools given in the above post,
do they work properly
www.huagati.com/dbmltools/
www.perpetuumsoft.com/Product.aspx?lang=en&pid=55&tid=linqtosqlsynchronization
Or is there any better approach for this problem.
The "official" approach is to simply delete any out of date tables from the designer then drag the updated table from your Server Navigator back on again. I've been using this method for well over a year now and so long as you make your data context changes at the same time you're updating the database you should be OK. It also gives you extra incentive to make sure you have your database structure in order before continuing.
There is also SQLMetal.
http://msdn.microsoft.com/en-us/library/bb386987.aspx
This is whats in our CreateDBML.bat file
call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86
sqlmetal /server:{server-name} /user:{username} /password:{password} /database:{databasename}
/dbml:..\..\Codebase\Domain\CompanyName.ProjectName.Domain\Entities\ProjectName.dbml
/namespace:CompanyName.ProjectName.Domain.Entities /pluralize /views
sqlmetal /code:..\..\Codebase\Domain\CompanyName.ProjectName.Domain\Entities\ProjectName.designer.cs ..\..\Codebase\Domain\CompanyName.ProjectName.Domain\Entities\ProjectName.dbml
pause
Related
I learned play by following the tutorial on their website for building a little blogging engine.
It uses JPA and in it's bootstrap calls Fixtures.Deletemodels(), (or something like that).
It basically nukes all the tables every time it runs and I lose all the data.
I've deployed a production system like (sans the nuke statement).
Now I need to deploy a large update to the production system. Lots of classes have changed, been added, and been removed. In my testing locally, without nuking the tables on every run I ran into sync issues. When I would try to write or read from tables play would throw errors. I opened up mysql and sure enough the tables had only been partially modified and modified incorrectly in some cases. Even if I have the DDL mode set to "create" in my config JPA can't seem to "figure out" how to reconcile the changes and modify my schema accordingly.
So I have to put back in the bootstrap statement that nukes all my tables.
So I started looking into database evolutions within Play and read an article on the play framework website about database evolutions. The article talked about version scripts, but it said, "If you work with JPA, Hibernate can handle database evolutions for you automatically. Evolutions are useful if you don’t use JPA".
So if JPA is supposed to be taking care of this for me, how do I deploy large updates to a large Play app? So far JPA has not been able to make the schema changes correctly and the app will throw errors. I'm not interested in losing all my data so the fix on dev "Fixtures.deleteModels()" can't really be used in prod.
Thanks in advance,
Josh
No, JPA should not take care of it for you. It's not a magic tool. If you decide to rename the table "client" to "customer", the column "street" to "line1" and to switch the values of the customer type column from 1, 2, 3 to "bronze", "silver", "gold", there is no way for JPA to read in your mind and figure all the changes to do automagically.
To migrate from one schema to another, you use the same tools as if you didn't use JPA: SQL scripts, or more adavanced schema and data migration tools, or even custom migration JDBC code.
Have a look at flyway. You may trigger database migrations from your code or maven.
There is a property called hbm2ddl.auto=update which will update your schema.
I would STRONGLY suggest to not use this setting in production as it introduces a whole new level of problems if something goes wrong.
It's perfectly fine for development though.
When a JPA container starts (say, EclipseLink or any other), it expects to find a database which matches #Entity classes you've defined in your code. If the database has been migrated already, everything will work smoothly; otherwise: probably it will fail.
So, long story short, you need to perform database migrations (or evolutions, if you prefer) before the JPA container starts. Apparently, Play performs migrations for you, before Play kicks off the database manager you configured. So, in theory, regardless the ORM you are using, Play decides when it's time for the ORM to start its work. So, conceptually it should work.
For a good presentation about this subject, please have a look at the second video at: http://flywaydb.org/documentation/videos.html
I have a small amount of experience using SVN on my development projects, and I have just as little experience with relational databases. I know the basic concepts like tables, and SQL statements, but I'm far from being an expert.
What I'd like to know is if there are any generic version control type systems like SVN, but that work with a database rather than files. I would like the same kind of features you get with SVN like the ability to create branches, create tags, and merge branches together. Rather than a revision number being associated to a version of a file repository it would be associated with a version of the database.
Are their any generic solutions available that can add this kind of functionality independent of the actual database schema? I'd be interested in solutions that work with MySQL or MS SQL Server.
I should also clarify that I'm trying to version control the data not the schema. I would expect the schema to remain constant. So really it seems like I want a way to create a log of all the INSERT, UPDATE, and DELETE requests sent the the database between each version of the data. That way any version could be recreated by resending all the SQL statements that have been saved up to the desired version.
You can script all your DDL, stored procedures and such to regular text files.
Then you can simply use SVN for database versioning.
I've never found a solution that works as well as Subversion, but here's a few things I've done that have helped:
Make scripts that will create the schema and populate any initial data. Then make an update script for each change after that. It's a fairly manual process, but it works. There's extra things that help like storing the current version number in a table in the db and making sure that the scripts are idempotent.
Store the full development db in Subversion. This doesn't usually work out too well for me if there is a lot of data or it is frequently changed. But in some projects is could work.
I keep and maintain create scripts in my version control system.
There are two things I can think of:
http://www.liquibase.org/ - provides a way of generally managing database changes. Creates files that get committed into source control, and it helps manage changes across different development databases, etc.
http://www.viget.com/extend/backup-your-database-in-git/ - this describes a strategy for backing up a database into source control, but the same strategy can be used just on the schema. In this scheme, the database would be in a separate area from your main code. (This can be used with other source control systems too.)
When I modify the structure of the table in Sql Server ,won't it be automatically reflected in the "Dbml" Layout designer ?Each and every time i have to delete the tables in "dbml' layout designer and drag the table from sql server.
It would be nice if you had the option to "refresh" keeping any local customizations that you've made, but the designer doesn't seem to work that way. You can, however, simply make the same updates (by hand) in the designer that you've made to the table by adding/deleting columns from the generated class in the designer.
If I were you I'd start using SqlMetal. SqlMetal is a command line application used for generating LINQ DataContexts. It can generate dbml's or just a set of classes for you to use in your project (it's pretty customizable). So create a batch file that calls SqlMetal and run it every time you make database changes and your project will always be up to date with the database.
If you don't want to run the batch file every time you update the database you could just run it every time you build your application with a pre-build step.
There are a number of ways to keep the L2S model in sync with the underlying database:
1) Delete the table(s)/classes involved from the designer surface and drag them back from the 'server explorer' thing.
...or...
2) Update the classes involved manually in the L2S designer.
...or...
3) Use third party tools with update capability (one such tool is my add-in: http://www.huagati.com/dbmltools/ , also mentioned in the Dec 2009 issue of MSDN magazine http://msdn.microsoft.com/en-us/magazine/ee819138.aspx)
...or...
4) Regenerate the entire DBML file using either the designer or sqlmetal.exe.
I am using LINQ2SQL in my current project. I have a quite a lot of tables ~30. When I create my DBML file I change some of the column names etc for readability.
Recently if I made a change to the table in the underlying Database I just deleted and re-added the table in the DBML file, but this is getting tedious. How can I mimic any changes to the database in the DBML file? (e.g. new column, drop column, new default constraint etc).
Out of the box, Linq-to-SQL has no update feature - amazing, but unfortunately true.
There's two tools I know of that get around this:
PLINQO is a set of CodeSmith code generation templates which handle DBML generation and offer lots of extra features (like generating one file per db entity) - including updates!
The Huagati tools offer updates and enforcing naming conventions for DBML and Entity Framework
Marc
I'm not expecting this to be the correct answer, but I thought I'd chime in anyway.
My approach has been to use the drag-n-drop feature for creating the initial DBML file. Then, any changes I make in my DB are also then made, by hand, in either the designer or in the DBML file (as XML) itself. (You can right-click on the DBML file, select Open With, and choose XML editor.) Sometimes it is much easier/faster to work with its XML instead of messing around in the designer.
I would only consider the deleting and re-adding, as you have been doing, if the changes were significant. For adding a new column, however, I'd suggest working directly with the dbml's XML, it's probably faster.
Good luck!
Welcome to the world of tedious! Unless I missed something, you're doing it the right way.
SubSonic looks like an interesting alternative, and boasts
It will also create your database on the fly if you want, altering the schema as you change your object.
As far as free solutions, there are a couple of blunt instruments that mostly move you away from using the O/R Designer: SQLMetal and Damien Guard's T4 templates.
There are multiple commercial solutions available that offer a lot more features.
The question you have to ask yourself is: Am I using the right ORM? LinqToSql has quite a few significant drawbacks, database change handling being only one of them.
Do not use the Visual Studio 2008 LinqToSql O/R Designer
The drawbacks of adopting Linq To Sql
How are you supposed to correctly use a Visual Studio Team System database project to implement version control on a sql server database?
This might seem overly generic but everything I've found so far online hasn't helped me in being able to achieve anything useful. I have managed to find functionality that appears to be similar to features that are in Redgate's tool Sql Compare but it definitely didn't seem as intuitive as their product.
From my understanding of how these db projects are supposed to work is that you're able to have a version of the database that either lives in Team Foundation Server (or inside the sql server itself) that you can check out to your local machine work on it and then check in the new changes which would allow for simultaneous development to work normally as it does for coding. Was I misinformed? Or is it just a complicated process to get setup?
Related is then how do you use it to deploy changes to the staging/production servers?
We don't use that, we simply script every thing and put it in source control like any other file and ALL deployments to prod are only through scripts pulled down from source control. I think the real key is that nothing gets put on prod except thorugh a source controlled script. Once the developer can't get his change to prod any other way (Devs should not have prod rights), there is no incentive to not put the change in source control.
Funny you should ask. I am the one responsible for getting our production databases under version control, and we're using Visual Studio Database Edition to do it. It is a fantastic tool. The very nice thing about this tool is that not only will it keep your schema under version control but it will validate your database schema as well and permit you to run code analysis against it. It also allows refactoring operations, and many other things.
Typically we work against a local development database, synch the changes back to VSDE, build the database to make sure there are no warnings or errors, and then create a deployment script for deployment to our production databases.
This is a simplified explanation of what and how we doing this, but I think it gives you a general idea of how it can be used. I'd be glad to answer any more specific questions you have.