I have a running JavaEE web application (WAR) whose Entities will be changed in the next version of the application. This also means structure changes in the underlying database of course.
What is the best way to keep your old data and migrate to the new Entity structure after an application rewrite?
Do I have to manually change the database structure before redeploying or are there other ways?
In EclipseLink 3.4, adding persistence properties to you persitence.xml.
<property name="eclipselink.ddl-generation" value="create-or-extend-tables" />
<property name="eclipselink.ddl-generation.output-mode" value="database" />
This feature is to allow creating database tables and modify any that already exist so they match the object model.
you would like to version control your upgrade and degrade db script with your codebase. your upgrade scripts should be able to assure the safety of your existing data. and you should always do a back up before you apply your changes. Try liquibase.
Related
At a conference yesterday, I learned about the importance of putting your database in source control. They showed us how to make a new Database project and import the database.
What I was wondering about is how I would change an existing project running on Entity Framework to utilize the database project's power?
Schema updates have always been done by using Entity Framework Migrations. I get that the Database project will be able to deploy database updates for me and save those update scripts to source control, but I would like to keep Entity Framework for querying my data (if that makes any sense at all).
Is it possible (or even: recommended) to use Entity Framework to access the database but manage the database using a Database project in Visual Studio ? How do you go about this?
I've tried searching for similar questions and using Google to find if anyone else is having the same problem, but no dice so far.
I should also state that I am considering using this in databases that also have stored procedures in them. These are not controlled through Entity Framework at all, and therefore are not in source control yet.
Thank you for your time.
What I was wondering about is how I would change an existing project
running on Entity Framework to utilize the database project's power?
Answer: I suggest you to see this course from Plural Sight : https://www.pluralsight.com/courses/code-first-entity-framework-legacy-databases
Is it possible (or even: recommended) to use Entity Framework to access the database but manage the database using a Database project
in Visual Studio ? How do you go about this?
Answer: Yes, it's possible and recommended. Your data project becomes the source of truth about the structure of your database. This is very powerful to keep control of all the changes and state of your database in one place (Visual Studio). The course from the first answer will teach you how.
I should also state that I am considering using this in databases that
also have stored procedures in them. These are not controlled through
Entity Framework at all, and therefore are not in source control yet.
Answer: I don't see any problem using stored procedures. The tool from the Plural Sight course will create the procedure in your source control and the reverse engineering will create a class/method for easy use of the proc.
I just came across the below alternative, which I didn't test though:
Generate Entity Framework Core classes from a SQL Server database project - .dacpac file
I believe this should be something to be considered
I developed an application like that, having 2 projects: application itself and the SSDT project for the database. The database changes were deployed via change scripts, and EF migrations were disabled in the application.
Everything worked fine, although it did bring a bit of an overhead. For example, it was a bit of a hassle to introduce major database updates / refactorings into the EF layer. For some reason, I was unable to reverse engineer database changes directly into the app, so I had to do it half-manually: creating new project, generate EF context for the entire database, and then copying new / changed files into the main application.
(Then again, it was almost 5 years ago. With luck, EF scaffolding has improved since then.)
I am using eclipse link jpa 2.0. I am using hana database. So I created views and generated java entity files using eclipse. The problem is, after starting Java Web application in Tomcat server 7, if any table data is modified, then view is not returning updated values. Even if I am running view with native query it is giving old values only.. please let me know what changes need to do in configuration level or entity creating level. ( I even added #Cacheable(false) also).
Assuming that when you say view you mean database views, perhaps the following existing answered question might help (though the link talks about Oracle instead):
Materialized View - Oracle / Data is not updating
You might be using some sort of materialized view made in the database that can be configured to refresh during certain events. In this case, the problem does not lie in Eclipselink's caching mechanisms, but in your database instead (as you mentioned that even native queries returned stale data).
i am using wso2 api-manager 02.01.00 on a linux system. The Api-Manager is deployed at Folder A. The Databases (h2) are deployed ad Folder B which is not in Folder A. The datasources in /repository/conf/datasources/master-datasources.xml are pointing correctly to the databases in Folder B. I configured it like that, because i want do preserve the databases if there is a deployment. (Becaus a fiew Developer are using the API-Manager and they don't want to loose their Data.) But it seem, that WSO2AM_DB.h2.db is created new if there is an api-manager-depoyment. I think this, because i had a look to the DB-Size. I started with a Size of 1750KB for WSO2AM_DB.h2.db. I published a view API's in the Manager and the Size increases to 2774KB. Then i did a Deployment and the size returned to 1750KB.
Effect is that API-Store/Publisher says "There are no APIS published yet".
But i could see the APIS at Application Subscriptions and in Carbon Resources at /_system/governance/apimgt/applicationdata/provider/admin.
I tried to force a new Indexing with this, but it doesn't change anything.
Could i configure at any place, that the Database should not be created/manipulated at start?
Meanwhile i'm really desperated of not solving this problem.
Maybe you could help me.
Thank you for your Time.
WSO2 does not recommend to run on H2 database. You need to use a production database such as mysql, oracle, etc. H2 is only for tryouts.
Basically, WSO2 servers store data in databases as well as use the file system. For this kind of a deployment, you need to do the following.
Point to an external database. If you are using this for demo purposes, still you can go with the current mode (H2 database).
Use dep-sync. The content which comes under the WSO2_HOME/repository/deployment/server location needs to be preserved. You can use SVN based dep-sync or rsync. Basic idea is that for a new deployment, you need to have the data of the previous deployment.
Solr Indexing preservation. If you have hundreds/thousands of APIs in the system, it would take time for indexing. To avoid that you can copy the content of WSO2_HOME/solr to the new deployment.
Spring Boot is a good framework to develop quickly applications. However, when creating an application binded to database, it seems some of the work must be done twice (I'm using Flyway):
create table creation SQL queries scripts
create Spring entites containing corresponding annotations
run application : the flyway script generates the tables
Writing scripts AND entites can be time consuming, and without added value. Is it possible to do it only once?
Thanks
Just set theese properties on your configuration file:
spring.jpa.properties.javax.persistence.schema-generation.create-source=metadata
spring.jpa.properties.javax.persistence.schema-generation.scripts.action=create
spring.jpa.properties.javax.persistence.schema-generation.scripts.create-target=create.sql
The schema file will be generated automatically in the project root. Hope it helps.
You can also use JPA Buddy plugin. It has a "Show DDL" menu where you can visualize the sql script for a selected entity. Really useful when you want to avoid creating everything manually.
I'm currently working on a Grails project which has a static production database with a lot of data in it. I would like to test my application using the production data, but instead of having to clone the production database I'd like to setup a proxy database to the production database.
Essentially reads of the database would go all the way to production database while writes would stop at a proxy database (preferably an h2 database). If a row was updated that came from the production database the row would be saved to the proxy database and returned, instead of the production's row, on subsequent queries.
I'd like to do all of this as transparently to the application as possible. My currently line of thinking is that I'd need to fork the Hibernate GORM implementation and make it support this use case. Has this been done before? Is there a better way?
Forking the Hibernate GORM implementation may not be a good idea. You will be stuck in your version and will have to, somehow, make this up to date with the original plugin (eg. bug fix, new implementations).
Maybe a custom TestMixin that allows you to override all registered domain classes, with new implementations of save(), get(), find() and etc can be an option. You can work with the metaClass to override this static methods and this will be triggered only on tests with the annotated mixin.
With this you can use multiple datasources in the test environment to determine which will be used.