I using JPA and MySQL in Spring boot. Howto make a initial content data of database?
Example, need create the basic sections, default admin user, etc.
Thanks.
I would recommend that you take a look at Flyweight, It is nicely integrated into SpringBoot.
We use it to create the initial database, and for adding new tables or modifying the database when deploying new version of our application.
I would recommend that you create a script /resources/db/migration/V1__Initial.sql Which just have the table layout and then a V2__data.sql with the initial data.
A script can only be run once, and you can't modify it after it has been run, this information is stored in a table named schema_version, which you will probably have to delete, or manipulate during development. Here is a link
to how it works - These days I would never do a real world project without using it.
Related
I'm working on a simple task of adding a new table to an existing SQL DB and wiring it into a SpringBoot API with SpringData.
I would typically start by defining the DB table directly, creating PK and FK, etc and then creating the Java bean that represents it, but am curious about using the SpringData initialization feature.
I am wondering when and where Spring Data + JPAs schema generation and DB initialization may be useful. There are many tutorials on how it can be implemented, but when and why are not as clear to me.
For example:
Should I convert my existing lower environment DBs (hand coded) to initialized automatically? If so, by dropping the existing tables and allowing the App to execute DDL?
Should this feature be relied on at all in production envrionment?
Should generation or initialization be run only once? Some tutorial mention this process running continually, but why would you choose to lose data that often?
What is the purpose of the drop-and-create jpa action? Why would
you ever want to drop tables? How are things like UAT test data handled?
My two cents on these topics:
Most people may say that you should not rely on automated database creation because it is a core concept of your application and you might want to take over the task so that you can lnowmfor sure what is really happening. I tend to agree with them. Unless it is a POC os something not production critical, I would prefer to define the database details myself.
In my opinion no.
This might be ok on environments that are non-productive. Or on early and exploratory developments. Definetely not on production.
On a POC or on early and exploratory developments this is ok. In any other case I see this being useful. Test data might also be part of the initial setup of the database. Spring allows you to do that by defining an SQL script inserting data to the database on startup.
Bottomline in my opinion you should not rely on this feature on Production. Instead you might want to take a look at liquibase or flyway (nice article comparing both https://dzone.com/articles/flyway-vs-liquibase), which are fully fledged database migration tools on which you can rely even on production.
My opinion in short:
No, don't rely on Auto DDL. It can be a handy feature in development but should never be used in production. And be careful, it will change your database whenever you change something on your entities.
But, and this is why I answer, there is a possibility to have hibernate write the SQL in a file instead of executing it. This gives you the ability to make use of the feature but still control how your database is changed. I frequently use this to generate scripts I then use as blueprint for my own liquibase migration scripts.
This way you can initially implement an entity in the code and run the application, which generates the hibernate sql file containing the create table statement for your newly added entity. Now you don't have to write all those column names and types for the database table yourself.
To achieve this, add following properties to your application.properties:
spring.jpa.hibernate.ddl-auto=none
spring.jpa.properties.javax.persistence.schema-generation.scripts.create-target=build/generated_scripts/hibernate_schema.sql
spring.jpa.properties.javax.persistence.schema-generation.scripts.action=create
This will generate the SQL script in your project folder within build/generated_scripts/hibernate_schema.sql
I know this is not exactly what you were asking for but I thought this could be a nice hint on how to use Auto DDL in a safer way.
who can help me to understand this scenario please. let say there is a client who have been using php as Backend, now he wants to merge his project from php to Spring knowing that he already has a full data and completly defined (mapping, primary key, tables), he export his data as sql (database.sql) so my question is how can we work and interact with this data in Spring Data ?
So you have the database export file(s), you create a new empty database and import those files there, configure your Spring Data to connect to the new db and stop using the Php app if you can (if you continue to use it you will have to somehow synchronize the two databases, more complicated)
I recently was working with liquibase which is capable of generating the initial DDL script for my JPA entities.
I am trying to do the same for my entities which has Neo4j as the store. Is there any library like liquibase which I can use to get my work done. Can someone put light on this ?
Is there a need in Neo4j to have initial scripts just like rdbms store needs initial CREATE(and other DDL scripts) scripts to insert,update etc ?
I don't want to use the auto capability of spring boot.
There is no need in Neo4j to create or update schema itself, as you're doing in SQL. Schema is dynamically builds from the data you have in your database.
But if you're trying to manage migration of the data stored in your database, you can take a look at liquigraph. It's able to manage a CYPHER queries within changesets.
I have an ERP application running with Oracle forms and Oracle database. Now I am planning to migrate this application to a java based enterprise application. will it be a good idea to keep the existing oracle database as back end and developing a web application with certain level of changes/additions in the DB design.
There are two facts to know before answer your questions:
has your database schema some oracle forms special structures or is it in 3rd normal form and simply stores data using keys and enforced referential integrity?
How much stored code contains your database?
Ad 1. Oracle forms don't have specific schema reqiurements. They work best if your schema if based on 3rd normal form. If your schema is like this, use it for new Java application. We have both forms and Java EE applications on same database schemas and is works fine.
Advantage is, if you have keys (primary, unique, foreign) in your schema. Use them when generating Java app.
Probably you will have to add #Version columns for optimistic locking (see https://docs.oracle.com/javaee/6/api/javax/persistence/Version.html). But there is not reason to build new schema for it.
Ad 2. Your will have to overwrite bigger part of database stored code (triggers, procedures, functions) to Java. In most cases this does not have dramatic impact to schema structure, but deal with it.
So - if your database schema is not tailored to some UI client needs AND you want only use a new client, use your schema. If not, create a new one.
One of the requirements for an ASP.NET MVC (3) app I'm working on is that it must be able to create and populate all required database tables, etc. if it's configured to use an empty database.
Since it's a standard ASP.NET MVC3 app, it uses the standard authentication tables (aspnet_*), along with a bunch of stored procedures and stuff.
What I'm trying right now is creating the tables through migrations (via MigratorDotNet) one by one as necessary (so far only made the aspnet_Users one), hoping they're not all needed; other stuff I'll need includes certain stored procedures, like CheckSchemaVersion.
How can I create these from inside an ASP.NET MVC app?
I also have a SQL dump of an empty ASP.NET MVC database (so it creates all the tables and stored procedures) to extract the relevant SQL from. As a super last resort, if I can somehow run this from inside my app, that may suffice as a solution.
If it matters, I'm using ActiveRecord (backed by NHibernate) with SQL Server 2008 Express .
This is indeed possible. The code is available in my application, Syzite, which is open-source (check AdminController.createAspNetStoredProcedures()).
The solution was to:
Store the procedures into a text file on the server
Iterate over all the lines
Find every set of CREATE PROCEDURE ... )\n as a procedure generation call
Create a System.Data.Linq.DataContext instance
Call instance.ExecuteCommand with the CREATE PROCEDURE code.