I was somewhat relieved when I came across this blog post which highlights the fact that other developers have also faced a loss of productivity when working with Grails.
The "convention over configuration" approach speeds up development and keeps the learning curve fairly easy for most developers, but the list of open issues on the Jira suggests that there are still some aspects that need tuning - or detuning in some cases (e.g. domain objects not having GORM functionality due to something missing in lazy decoration/injection).
I've been wondering what sort of risks are involved when you use a software product that is essentially just providing a layer of abstraction over several loosely related other products.
For example, what can you do if you want to upgrade to a later version of one of the underlying technologies (for a fixed bug, or to use a new feature), when the layer above that hasn't been tested or made configurable for that new release? At present, I would expect that you would be stuck with whatever version is compatible with your version of Grails. This could change once OSGi becomes a bit more mainstream, allowing for the use of multiple versions of the same libraries within a single application. I wouldn't want to rely on that being the saviour of any application of mine though.
Stephen Souness, a Java developer who moved back to New Zealand after over a decade in London, sharing some thoughts on what's happening in the world of Cloud computing, Java and database technologies.
Showing posts with label GORM. Show all posts
Showing posts with label GORM. Show all posts
Monday, 22 June 2009
Sunday, 24 May 2009
Upgrading fixed updating, but may have broken creation.
It's a bit late in the evening for me to give a detailed account of what exactly I did, why, and what I found - so here's the short version.
Grails 1.1 was misbehaving whenever we tried to update an existing persisted object.
Grails version 1.1.1 was shown as fixing that particular issue.
I volunteered to be the guinea pig to be the first in the office to try upgrading.
Hurdle 1 - Original Grails 1.1.1 download included an install script with a Windows specific issue
Hurdle 2 - Maven plugin for Grails also would not play nicely (something about a dependency introduced by one of the minor new features added in Grails 1.1.1)
...
It works - even the updates to existing objects make it to the database without throwing exceptions etc. Hoorah!
A couple of days later we struck an issue where Groovy was unable to determine that an object was supposed to have GORM methods injected. The symptom being that it was unable to find a property (actually method) called save.
Mutter mutter mutter....
The workaround for that case has been to add some code to the BootStrap.groovy file to force Grails/GORM to be aware of that type of object - preventing us from relying on lazy initialisation.
Grails 1.1 was misbehaving whenever we tried to update an existing persisted object.
Grails version 1.1.1 was shown as fixing that particular issue.
I volunteered to be the guinea pig to be the first in the office to try upgrading.
Hurdle 1 - Original Grails 1.1.1 download included an install script with a Windows specific issue
Hurdle 2 - Maven plugin for Grails also would not play nicely (something about a dependency introduced by one of the minor new features added in Grails 1.1.1)
...
It works - even the updates to existing objects make it to the database without throwing exceptions etc. Hoorah!
A couple of days later we struck an issue where Groovy was unable to determine that an object was supposed to have GORM methods injected. The symptom being that it was unable to find a property (actually method) called save.
Mutter mutter mutter....
The workaround for that case has been to add some code to the BootStrap.groovy file to force Grails/GORM to be aware of that type of object - preventing us from relying on lazy initialisation.
Subscribe to:
Posts (Atom)