Grails is a "full stack" framework. Which means that it will help you with the whole application, including persistence.
The easiest way to handle your relational data in a Grails application is to let Grails do it for you. Grails will use Hibernate to create your database artifacts based on your domain classes. To take advantage of this you just need to follow a simple convention.
If you have an existing database that you need to access from a Grails application you have to do a bit more work, but it's still not that difficult (usually). My preferred mechanism for mapping to an existing DB is to use Grails' mapping DSL.
http://grails.org/GORM+-+Mapping+DSL. You can also use JPA annotations in your domain classes or you can create Hibernate mapping files and place them in your application's conf/hibernate directory. You can read more about these approaches here:
http://grails.org/Hibernate+Integration
Weak points:
The first one is a practical limit of one data source for domain classes. There is a plugin that helps with this somewhat, but there are still limitations. I don't know if anyone is working to improve this other than the developer of the plugin in question.
Next, is the testing. This has improved significantly and I don't have any complaints about it but I've heard that Rails has better testing support baked into it, I know that there are several plugin developers working to improve the Grails testing story and they are coming up with some cool stuff.
Third, is the large stack traces that you get with errors in Grails. They do get huge, but this doesn't really bother me (at least once I increased my console buffer size). This has also gotten better with some stack trace sanitization in recent versions of Grails, but I still hear people complain about it.
1. Memory :- I do not believe this was expected. Double the size of war file <not a big issue> and amazing amount of heap space and objects it holds. Brought down my production tomcat (shared with other Spring web applications). I have generous amount of memory, processing power and heap size (tuned)
2. Legacy database support *** :- I do not want to use standard id based tables or simple String. I had to do a lot of coding to take care of Complex composite keys with foreign key relationships. Also I do not like the way you have to query other tables (not in the domain)
3. Plugins :- Need to be more mature. Some basic plugins like searchable, filter pane, export work for basic feature. Well - I don't think any user uses these basic features and then you need excessive customization to get these to work for tech savvy user. For e.g. Ms Access can perform better searches and filters. I have identified some bugs (may be fixed in the newest release)
4. Documentation and more examples :- I know the basics but some plugins and strategies don't always work as given in the documentation. Need more complex examples and tutorials.
So this is arguable not a weak point. Most Grails users would consider this a strong point and feature of grails, but I find it to be somewhat of an anti-pattern. I don't like the fact that in a grails GSP I can write groovy code. So for example...
- <g:each in="${Book.list()}">
- <p>Title: ${it.title}</p>
- <p>Author: ${it.author}</p>
- </g:each>
<g:each in="${Book.list()}"> <p>Title: ${it.title}</p> <p>Author: ${it.author}</p> </g:each>
Note Book.list(). This goes against everything I learned while growing up with JSP and the EL. You now have the ability to call arbitrary methods on objects directly in the view. And I think this is a horrible thing to do. I suppose this could have also gone in the Grails best practices thread in that I'd say a best practice is to avoid scripts in GSP like the plague.
A) promoted with doing this as demos and examples and/or B) didn't allow the alternative poor design choice.
