I'm trying to learn martini, coming from Rails. What's being used for database migrations in the martini world?
There is no such thing in martini. It is just a helper for writing web services. If you want database migrations, or a database at all, use third-party packages.
An example tool stack would be:
goose for creating migrations
gorp for a database object layer
This or a completely different setup, e.g. using Go's standard database package, can be used with martini.
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.
I am new with Laravel and started my personal project.
Laravel provide migrations for creating schema for our databases. I have difficulties on implementation choice. The ideas I have are:
Create database schema using Illuminate\Support\Facades\Facade\Schema provided by Laravel, for example:
Schema::create('users', function (Blueprint $table) {
$table->increments('id');
$table->string('username',300)->unique();
$table->string('email',300)->unique();
$table->string('password',100);
})
Create schema using ERD Designer like Mysql Workbench, export the diagram to sql and finally execute the sql in Laravel using DB::statement
I'm trying to google which method is better, but no answer satisfy me.
Which methods is the better or commonly used in industry? If you have any other suggestion I'm happy to know it.
Laravel Schema is an abstraction and, for the most, database indipendent, that is, if there is already a grammar in the laravel source or in an external library you can use the same migrations with different Database Engines with minor issues.
If you use Raw SQL you could, in case, depend on the actual Database Engine you use.
Laravel ships with these grammars: MySQL, PostgreSQL, SQLite and SQLServer.
If you use the build-in Schema you can use the same migrations in any of the databe engines above without worry too much about the actual SQL implementation.
Consider that many developers have a local dev environment with a simple database engine like SQLite, and sometimes when they start a project they don't even know the database engine that will be used in production. Think about the case you want to change hosting provider or you have a demo project on a cheap provider and the production elsewhere.
I am new to Beego as well as Go. I read its documentation but it puts every ORM operation in the main package instead of model package. I can't understand how to organize the code. I am really very confused.
You can feel free to follow steps as below, and try to build your first database program.
Build [Models]
According to the table structure of your database.
Initialize the ORM
New an ORM instance
Operate CRUD as your want
Link:
Guidance for Beego/orm configuration
https://beego.me/docs/mvc/model/orm.md
Guidance for operating CRUD on Beego/orm
https://beego.me/docs/mvc/model/object.md
I am new to using Laravel, and I'm currently learning about Laravel's database migration and seeding features.
It's working with the command prompt, but I can migrate and seed in phpMyAdmin as well. What are the advantages and disadvantages of migrating and seeding within Laravel as opposed to phpMyAdmin?
From Laravel docs on Migrations & Seeding:
Migrations are a type of version control for your database. They allow a team to modify the database schema and stay up to date on the current schema state.
A simple search for why database migration also gives me some pretty decent results. One of the easiest to understand is a page by FlywayDB (I have no idea who they are until I search this term up):
Database migrations are a great way to regain control of this mess. They allow you to:
Recreate a database from scratch
Make it clear at all times what state a database is in
Migrate in a deterministic way from your current version of the database to a newer one
The illustration they made perhaps explain it more clearly, so you may want to check it out.
I have a problem with migrating my SQLite3 database to PostgreSQL. How and what do I need to do?
I am searching the internet, but find only migrations from MySQL to PostgreSQL.
Can anyone help me?
I need to convert my SQLite database to PostgreSQL database for Heroku cloud hosting.
You don't want to try to do a binary conversion.
Instead, rely on exporting the data, then importing it, or use the query language of both and using selects and inserts.
I HIGHLY recommend you look at Sequel. It's a great ORM, that makes switching between DBMs very easy.
Read through the opening page and you'll get the idea. Follow that by reading through the cheat sheet and the rest of the documentation and you'll quickly see how easy and flexible it is to use.
Read about migrations in Sequel. They're akin to migrations in Rails, and make it very easy to develop a schema and maintain it across various systems.
Sequel makes it easy to open and read the SQLite3 table, and concurrently open a PostgreSQL database and write to it. For instance, this is a slightly modified version of the first two lines of the "cheat sheet":
SQLITE_DB = Sequel.sqlite('my_blog.db')
PGSQL_DB = Sequel.connect('postgres://user:password#localhost/my_db')
Base all your subsequent interactions with either database using SQLITE_DB and PGSQL_DB and you'll be on your way to porting the data.
The author of Sequel is very responsive and is a big fan of PostgreSQL, so the ORM has great integration with all its features.