Question

This is something I have been struggling about for some time now. The thing is: I have many (20 or so) static arrays of values. I say static because that is how I’m actually storing them, as static arrays inside some domains. For example, if I have a list of known websites, I do:

class Website {
   ...
   static websites = ["web1", "web2" ...]
}

But I do this just while developing, because I can easily change the arrays if needed, but what I’m going to do when the application is ready for deployment? In my project it is very probable that, at some point, these arrays of values change. I’ve been researching on that matter, one can store application properties inside an external .properties file, but it will be impossible to store an array, even futile, because if some array gets an additional value, the application can’t recognize it until the name of the new property is added where needed.
Another approach is to store this information in the database, but for some reason it seems like a waste to add 20 or more tables that will have just two rows, an id and a name.
And the last option, as far as I know, would be an XML, but I’m not very experienced with those. It seems groovy has a way of creating and reading XML files relatively easy, but I don’t know how difficult would be to modify an XML whose layout is predefined in the application.

Needless to say that storing them in the config.groovy is not an option since any change will require to recompile.

I haven’t come across some “standard” (maybe a best practice?) way of dealing with these.

So the questions is: Where to store these arrays?

Answer 1

1. Use Enum for a fixed set of attributes. Do this, if you rely at some places in your code on some concrete values.
2. If you do not rely on the attributes within your code (which you obviously don’t), use a String-type. In this case, if you need to provide a select box, just do a distinct-query on this property in your database.
3. Default: Use a domain class per dynamic set of attributes. Another table is OK.