Play2 and MySql
Happened so far
I have developed my Play2 app using H2 in memory database. Wonderful! Next step is to set up local Postgres, and after a while also this works ok. WIth Postgres I don't anymore have automatic evolutions in use, but H2 was generating Postgres compatible SQL after some JPA annotation tuning and I felt happy.
BTW: All this was possible since Play2 has really neat feature called evolutions
MySQL comes to Play
My organization is using MySql. Fine. I try with existing sql generated by evolutions. SQL has errors. No big deal -- yet.
I feel I could live with couple of new reserved words like "lines", which couldn't be anymore used as fields name as MySQL uses "lines" on ETL definitions. So; I rename fields on JPA classes and generate SQL again. No problem.
After this comes shock. Play2 / Ebean autogenerated SQL is nice, readable, and follows SQL standard(!), and I had not paid attention to fact that MySql doesn't follow SQL standards.
You find more of the problem from here
Decision
Oh my. Should I define all my seqences to be autoincrements? And what about referential integrity. Use InnoDB? Annotate all ID's with @GeneratedValue? And just accept other MySql anomalies? And be locked to develop usign MySql?
No. I will play political games, and try to convince my organization to accept one more database -- for greenfield project this might be accepted. Let's see.
Further steps
There's lot of comparisons, but many of them look like flamewars. It's important to notice, that whichever you want to use is not only up to your own preferences, but also your use case. And your company's policy, also.
Since MySql feels like no-go to me, I'll need to go deeper and see how to justify Postgres - or file based H2.
No comments:
Post a Comment