|
|
|
|
|
by stephen
4065 days ago
|
|
I imagine most Java web/services would consider it bad style/coupling to pick just one data back end (e.g. assume everyone uses JPA or Hibernate or what not), which would be needed to support migrations. Even after Rails, the Java ecosystem is less "everything out of the box" and more "build your own stack". There are some exceptions, e.g. Grails and Play. Although both of those have migration modules: https://www.playframework.com/modules/migrate-1.3.2/home https://grails.org/plugin/database-migration (First hits from Google, so apologies if those aren't the latest/best results.) And, even then, I think both Grails/Play also try to be backend-agnostic, e.g. the migrations being plugins instead of first-class/backed in, like Rails which assumes "yeah, you'll basically always use a relational db". Also, re migrations, a shameless plug for my ORM that relies on migrations+the database schema to codegen the rest of the boilerplate: http://joist.ws/. |
|