Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to handle Play Framework 2 database evolutions in production

It seems that whenever I change my models, Play Framework asks me to run a script that deletes my entire schema and recreates it. Obviously this won't work for production, so what is the proper way to handle this in production?

Note, I'm using ebean and Postgres, and hosting on heroku.

like image 543
TomahawkPhant Avatar asked Jan 30 '13 23:01

TomahawkPhant


People also ask

Is Play framework still used?

Play is rock-solid and used by hundreds of thousands of Java and Scala developers every month. Play is still extremely relevant to today's application and web development and has a passionate and very capable community around it ensuring that it has many good years left.

How do I run Playframework?

For running Play Framework applications with Intellij Idea tools you need to download and install Scala plugin. You can run you play-app via command line executing play run under the application root directory.

How does play framework work?

The Play framework is a web framework for the JVM that breaks away from the Servlet Specification. Play embraces a fully reactive programming model through the use of futures for asynchronous programming, work stealing for maximizing available threads, and Akka for distribution of work.


Video Answer


1 Answers

Unfortunately Ebean can create only CREATE DDL (and not UPDATE DDL) (as answered on their group), therefore you need to switch to manual evolutions ASAP.

some rules:

  1. Always backup your live DB before implementing any changes :)
  2. ebean plugin recreates whole DDL if it has only 1.sql evolution created by it
  3. You need to remove two first comments from 1.sql and start to writing own evolutions with next numbers 2.sql, 3.sql etc. Try to place as many models/fields as possible before switching to manual evolutions. The biggest part will be done automatically by plugin.
  4. manual evolutions should contain ALTERS to existing tables/columns instead of DROP/CREATE, they should have both: Ups and Downs for each change.
  5. try to place as many changes in each evolution as possible, it's easier to manage then writing separate evolution for each small change.

De facto sometimes it's just easier to modify DB structure with DB gui, anyway it works mainly for the single developer... when you need to share your code with other developers writing evolutions will be better option.

If after some time you'll add next 'big' portion of new models you can enable temporary auto DDL again and using local git just to copy new parts. Then revert to own revolution and paste new parts generated by Ebean plugin.

like image 59
biesior Avatar answered Nov 11 '22 18:11

biesior