Exact matches only
Search in title
Search in content
Search in posts
Search in pages
portfolio
Filter by Categories
ADAM
Architecture
Big Data
Bio-IT World
Bioinformatics
Blog
Cases
cBioPortal
Consultancy
CTMM TraIT
Data Curation
Data Management
FAIR
Galaxy
Harry van Haaften
IMI EMIF
IMI ETRIKS
IMI Translocation
Irina Pulyakhina
Janneke Schoots
Jarno van Erp
Jojanneke Blaak
Joris Borgdorff
Kees van Bochove
Maxim Monait
Natalia Boukharov
OMOP and OHDSI
Open source
Peter Kok
Pieter Lukasse
Piotr Zakrzewski
RADAR CNS
Rianne Jansen
Riza Nugraha
Services
Seth Snel
Sjoerd van Hagen
Software Development
Software Engineering
Software licenses
Software licenses
Solutions
Spark
Team
Topics
Translational Research
tranSMART
TranSMART 2.0
Uncategorized
Ward Weistra
Wibo Pipping

@TheHyveNL

Using the Grails Object Relational Model tends to work quite well when using conventional, structured data. At that point the type of database you are using, relational or otherwise, doesn’t really matter. GORM’s dynamic finders [1] are a pleasure to use. Also of note are the way in which one can add custom validation functions [2] or switch between deep and shallow validation on the fly [3], it’s cascading behaviour options and lazy and eager fetching options [4]. However, there is at least one reason why one might want to avoid using such a layer, and thus lose access to this functionality.

When writing in a highly iterative manner, as might occur when working on a prototype, it can be of benefit to use a schemaless database like MongoDB. One might find that using a more conventional approach to Grails-based development, with Domain objects that dictate the exact structure your persistent data can have, can take away a lot of the benefits of using a schemaless database, which doesn’t care much what structure your data has. Where one does use GORM, things may turn out to be a lot less easy to update or refactor than one had hoped. For one, this requires writing database upgrade scripts, as Grails will complain when handling Domain objects that do not have the expected fields set in the expected manner – and rightly so! Another thing is that some views may have been written in a less flexible way, requiring additional work. This additional work can slow down your progress considerably, and some of the advantages of using GORM don’t really surface when writing a prototype.

One might choose to skip creating Domain objects and have a service talk directly to the database instead. This can cut down on the amount of work required when making a change in how data is stored, because your database is schemaless. Just as important is that the related functionality should be written in a modular and layered manner, such that a minimum of code needs to be rewritten.

If you are using MongoDB or a similar database system because of it’s schemaless nature, and specifically when you are approaching your project in an agile manner, it may be beneficial to write your own, more flexible ORM layer. Should any views be using that data, try to make sure your views are set up in a flexible manner as well, and that there is a proper separation of concerns.

Leave a Reply

Your email address will not be published. Required fields are marked *

@TheHyveNL