I realize this has flame potential, please refrain. That being said, I'm interested in what databases people have used with Grails. What positive experiences and what horror stories are out there?
I love MySQL, but there are a few significant bugs that are impacting me between Hibernate and MySQL, particularly as it pertains to index creation. So I guess my question is really, what is the most stable database for integration with Grails? Or what database has the fewest bugs with respect to Grails?
Or what database has the widest use in conjunction with Grails? I also realize that these questions are somewhat orthogonal and opposing. Anyway, I'd like to open it up to discussion.
I use Hibernate in enterprice apps since version 1. My personal chart is
Oracle: fast stable lot of dba knows it and hao to tune performace backups end so
SQLServer: same as above (but not as fast as Oracle)
DB2: not so easy to use with hibernate(I got several issues with date and char datatype)
MySQL: not so easy to manage or find professional support (may be different for you) but Hibernate stuff works great.
As Gregg said, this is a hibernate question - Grails does all it's DB interaction via that (except for any custom SQL you write).
The only problem you might hit is with the GORM DSL not correctly creating any tricky hibernate mappings you require for a particular DB (especially if it's a legacy one). But GORM is pretty mature these days and I personally haven't hit any issues lately.
We run MySQL in production on a public web application and it has been fine. We've also deployed 'enterprisey' apps on top of Oracle which also went well except for a couple of issues with id generator configuration if I recall correctly. But I think those have been fixed in the latest Grails version.
In summary, go with your gut feel based on previous experience with hibernate.
cheers
Lee
Related
The database for one the application that I am working on is not confirmed yet by the business.
Best guess is Oracle and DB2.
What I've heard is initially the project will go live with DB2 V9 and then to Oracle 11g.
We are using Spring 3.0.5, Hibernate 3.5, JPA2 and JBoss 5 for this project
So what are the best practices here going into the build phase and test phase?
Shall I build using DB2 first and worry about Oracle later (this
doesn't sound right)?
Or, shall I write using JPA (Hibernate) and
then generate the database schema?
Or something else?
PS: I've no control over the choice of the DB, what and when, as these are strategic decision made by people sitting in nice rooms getting fat cheques and big bonuses.
Thanks,
Adi
Obviously you are loosing the access to specific features of the database if you are writing your application database agnostic. The database is, except for automatic optimizations done by JPA and Hibernate, reduced to common features. You have to set some things to automatic and trust JPA/Hibernate to do it right that you could set specifically if you knew the database (e.g. id generator strategies).
But it seems that the specific developer features of the database are not relevant for the decision so they can't be relevant to the application. What other reasons may influence the decision (like price, money, cash, personal relations, management tools, hardware requirements, existing knowledge and personell) can only be speculated about.
So IMHO you don't have a choice. Strictly avoid anything database specific. That includes letting the JPA/Hibernate generate the schema (your point #2). In this project setup you shouldn't tinker with the database manually.
Well... sadly there ARE some hidden traps in JPA/Hibernate developement that make it database dependent (e.g. logarithmic functions are not mapped consistenly). So you should run all your tests against all possible databases from day one. As you write "Best guess is..." you should just grab any database available and test against it. Should be easly setup with the given stack.
And you should try to accelerate the decision about the database used, if possible.
Just "write using JPA (Hibernate)" develop it to be de database agnostic. Put all you business logic in java code not stored procedures.
If you are using spring you don't need jboss you could use just tomcat, about a quarter of the foot print, and much simpler imho.
Spring vs Jboss and jboss represents all that is bad, while spring represents all that is good in Java enterprise development
We have add this issue and had to migrate late in the project, leading to a lot of extra works, frustrations and delays.
My advise is to define an abstract layer. Go to the point you may have a data model without any database, say with tables or text files.
Then when you have to switch to some database, you can optimize for it, while staying free to continue application development on any already developped model. So you don't delay the developpers on the app while one is tuning the DB2 layer. When everything is duly validated, the team can switch on it.
I will disagree with the currently accepted answer suggesting avoiding database specific things. From a performance perspective, that would be a pity, and it's definitely doable.
JPA/Hibernate and also jOOQ can abstract over a lot of things and if you're using the query builder APIs of either technology (criteria query in JPA, or jOOQ for more advanced SQL), you can get very far in a vendor agnostic way without removing all the vendor specific stuff. For example, you can easily create a vendor specific predicate like this:
.where(oracle ? oracleCondition() : db2Condition())
What you should do from the very beginning of such a project, once you know you'll have to support both dialects is to run integration tests on both database products. For this, I recommend testcontainers, which makes running such tests quite simple. If you have to add support for another dialect, and if you're using one of the above abstractions, you can simply add another testcontainers configuration, check if your application still works, tweak 2-3 things, and you're set.
Disclaimer: I work for the company behind jOOQ.
If I choose RavenDB for a fairly standard CMS-like web application, what do I lose compared to SQL Server?
EDIT: There is a word "benefits" in the title which is a little controversial term. Maybe I should have said something like "possibilities" or "features", hope it's clear what I'm after.
A few things that come to mind (but I'm new to RavenDB so this is just a few suggestions, some may be wrong, I hope someone would provide a more complete and accurate list):
Quick but customizable administrative interface using ASP.NET Dynamic Data (there is some built-in Silverlight admin application but I'm quite sure that it wouldn't replace a full-fledged admin section in my case)
Possibly some querying capabilities? Or can Raven indexes replace virtually every SQL query I might think of?
Entity Framework integration (I know some people hate EF but I think that being an EF provider means that you can easily publish the data as OData, use EF code-first etc., right?)
Azure deployment (not true according to comments)
Myriad of SQL querying / management tools
A more complete / accurate list would be greatly appreciated.
(Note: I'm not saying that I will need all (or any) of those, I'd just like to understand what's going to be unavailable if I choose RavenDB. Also, please don't discuss RavenDB strengths, I am aware of them and they are easily digestible from the official website.)
You may want to look # these 2 recent blog posts by Ayende (RavenDB creator) on when you should use RavenDB and when you shouldn't.
When should you use ravendb
When should you not use ravendb
Beyond the technology, you should consider your team members as RavenDB is an adjustment in thinking for those of us who have backgrounds in RDBMS. What type of stretch will this be for those involved? Will your users expect reports and what will the say when you tell them that you did not consider answering the questions that they want answered when you create the indexes for the document database? While you get a big boost in productivity when designing and implementing your domain, document databases are different than SQL.
Quick but customizable administrative interface using ASP.NET Dynamic
Data (there is some built-in Silverlight admin application but I'm
quite sure that it wouldn't replace a full-fledged admin section in my
case)
ASP.NET MVC supports scaffolding based on POCOs since second version. But it's not so quick'n'dirty solution.
Possibly some querying capabilities? Or can Raven indexes replace
virtually every SQL query I might think of?
You should to think about your queries first. Raven DB is not reporting database.
Entity Framework integration (I know some people hate EF but I think
that being an EF provider means that you can easily publish the data
as OData, use EF code-first etc., right?)
You are so focused on tools. Code First is the way how you work with document databases. Why you need OData? RavenDB has REST API out of the box.
WCF RIA Services (Silverlight).
You'll need to do all that WCF plumbing work.
I've no previous experience with tools like Liquibase and similar. Up to now the way I've usually managed deployment into production on apps using Hibernate was using manual SQL to modify the tables, as they were quite simple apps (the complex ones didn't use it...don't ask please :P).
I've wanted to use Evolutions in Play, but I see it clashes heavily with Hibernate in development, making it a pain and not a realistic option. In development Hibernate manages everything easily so there is no point on using Evolutions, but we wanted to keep the structure (files) to make it easier to migrate the app in production mode. But due to the clashes it doesn't seem worthy.
Liquibase had a Play module but it seems to have been discontinued since Evolutions was released (I wonder why, as I believe it would work wonder with Hibernate).
The question(s) would be:
How do you manage database migrations of apps in production?
What's the usual procedure/steps you use when your model changes between releases and you have to deploy to production?
Any specific tool or feature of Hibernate we are overlooking, or just old-faithful SQL Alter table and similar?
Focusing on Play Framework, how do you manage this?
What is often the case is that an application has two phases in its life cycle - initial development and post-production "maintenance". My experience is that often, all the big database changes happen in the first phase. Let yourself be flexible there by relying on Hibernate, then when you go to production, you take a schema dump, roll that on production with Evolutions, and manage your DDL manually from there.
In the second "phase" (I'm an agile guy, I hate the word ;-)), schema changes often include DML as well because you have to calculate initial values for new columns, etcetera. Also, you'll usually be spending more time on coding than on schema changes, so the whole manual experience becomes a bit less painful :).
(Having said that - I'd love a better integration between Evolutions and Play/Hibernate, like having the option to record the DDL that Hibernate spits out to the evolutions directory)
Well you ask a very good question. I struggled with this problem on grails, so I have not really a solution, but some thoughts. I will start with a comparison of Evolutions with Liquibase:
Liquibase is a matured solution, even if the plugin isn't under development any more, the underlying library is it. So I think it's an acceptable solution.
If you use Evolution you have one big disadvantage compared with liquibase: You must write your SQL directly, so the scripts depends on your database-system. Think abouts booleans and the representation in different databases. So you lost benefit Hibernate gives you.
Now to the general problem. I think you have to options:
Let Hibernate handle the database structure for you. Only in cases Hibernate can't do the job, you use liquibase or evolutions. Unfortunately you can run into some troubles if you have complicated update scenarios. How ever you win that your development is faster.
You ignore all DDL-Features from Hibernate and do everything with liquibase or evolutions. This is the most reliable and robust solution, but obviously you have much more work in development.
So what is my recommendation? I would try the following approach: Develop with an distributed version control system, like bzr or git. Then use feature-branches. Use for feature branches always the hibernate functionality. Before you merge the stuff into the trunk, create liquibase-script. These script can be generated by liquibase with some manual customizing). So you can develop a feature very quick and has in trunk always the robust solution 2.
How ever be aware that this isn't a proofed approach in great project. I only tested this strategy with Hibernate and Liquibase on a small project - it works fine.
So would be great to get feedback.
Regarding having hibernate spit out the SQL to get you started to use Evolutions or Flyway, take a look at this: http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/toolsetguide.html#toolsetguide-s1-6
EDIT: I actually made a plugin to bootstrap your migration script. I think it might be useful to most of the people that come across this thread:
http://web.ist.utl.pt/~joao.a.p.antunes/2014/08/09/play-2-2-x-jpa-hibernate-database-migration
Cheers!
I have a project for a class which requires that if a database is used, options exist for the user to pick a database to use which could be of a different type. So while I can use e.g. MySQL for development, in the final version of the project, the user must be able to choose a database (Oracle, MySQL, SQLite, etc.) upon installation. What's the easiest way to go about this, if there is an easy way?
The language used is up to me as long as it's supported by the department's Linux machines, so it could be Java, PHP, Perl, etc. I've been researching and found info on ODBC, JDBC, and SQLJ (such as this) but I'm quite new to databases so I'm having a hard time figuring out what would be best for my needs. It's also possible there may not be a simple enough way to do this; the professor admitted he's not a database guy either and he seemed to think it would be easy without having a clear idea of what it would take.
This is for a web app, but it ought to be fairly straight forward, using for example HTML and Javascript on the client side and Java with a MySQL database on the server side. No mention has been made of frameworks so I think they're too much. I have the option of using Tomcat or Apache if necessary but the overall idea is to keep things simple, and everything used should be able to be installed/changed/configured with just user level access. So something like having to recompile PHP to use ODBC would be out, I think.
Within these limitations, what would be the best way (if any) to be able to interact with an arbitrary database?
The issue I think you will have here is that SQL is not truely standard. What I mean is that vendors (Oracle, MySQL etc) have included types and features that are not SQL standard in order to "tie you in" to their DB, such as Oracle's VARCHAR2 and so on.
When I was at university, my final year project was to create an application that allowed users to create relational databases using JDBC with a Java front-end.
The use of JDBC was very simple but the issue was finding enough SQL features/types that all the vendors have in common. So they could switch between them without any issues. A way round this is to implement modules to deal with vendor specific issues and write ways to translate between them. So for example you may develop a database for MySQL with lots of MySQL specific code in that, but then you may want to use Oracle and then there are issues, which you would need to resolve.
I would spend some time looking at what core SQL standard all the vendors implement and then code for these features. But I think the technology you use wouldn't be the issue but rather the SQL you create.
Hope this helps, apologies if its not helpful!
Well, you can go two ways (in Java):
You can develop your own classes to work with different databases and load their drivers in JDBC. This way you will create a data access layer for yourself, which takes some time.
You can use Hibernate (or other ORMs). This way Hibernate will take care of things for you and you only have to know how to use Hibernate. Learning Hibernate may take some time, but when you get used to it, it can be very useful for your future projects.
If you want to stick Java there Hibernate (which wouldn't require a framework). Hibernate is fairly easy to use. You write HQL which gets translated to the SQL needed for the database you're using.
Maybe use an object relational mapper (ORM) or database abstraction layer (DAL). They are designed to provide a standard API to multiple database backends, making it possible to switch between different backends with minimal or no changes to your code. In Python, for example, a popular ORM is SQLAlchemy, and an excellent DAL is the web2py DAL (it's part of the web2py framework but can be used as a standalone DAL outside the framework as well). There are many other options in other languages as well.
use a framework with database abstraction layer and orm . try symfony or rails
There are a lot of Object relational database frameworks, unless you prefer jdbc. For simple/small applications this should work fine.
We have a new django powered project which have a potential heavy-traffic characteristic(means a heavy db interaction). So we need to consider the database scalability in advance. With some researches, the following questions are still not clear to us:
coarse-grained: how to specify one db table(a django model) to a specific db(maybe in another server)?
fine-grained: how to specify a group of table rows to a specific db(so-called sharding, also can in another db server)?
how to specify write and read to different db?(which will be helpful for future mysql master/slave replication)
We are finding the solution with:
be transparent to application program(means we don't need to have additional codes in views.py)
should be in ORM level(means only needs to specify in models.py)
compatible with the current(or future) django release(to keep a minimal change for future's upgrading of django)
I'm still doing the research. And will share in this thread later if I've got some fruits.
Hope anyone with the experience can answer. Thanks.
Don't forget about caching either. Using memcached to relieve your DB of load is key to building a high performance site.
As alex said, django-core doesn't support your specific requests for those features, though they are definitely on the todo list.
If you don't do this in the application layer, you're basically asking for performance trouble. There aren't any really good open source automation layers for this sort of task, since it tends to break SQL axioms. If you're really concerned about it, you should be coding the entire application for it, not simply hoping that your ORM will take care of it.
There is the GSoC project by Alex Gaynor that in future will allow to use multiple databases in one Django project. But now there is no cross-RDBMS working solution.
There is no solution right now too.
And again - there is no cross-RDBMS solution. But if you are using MySQL you can try excellent third-party Django application called - mysql_replicated. It allows to setup master-slave replication scenario easily.
here for some reason we r using django with sqlalchemy. maybe combination of django and sqlalchemy also works for your needs.