The discussion started in another thread:
gene wrote:During the last days I tried to develop a concept for saving our "data lists", so that we can advance to create a first "real" running prototype based on our data model (or at least a part of it). It would be great to use enumerations, but that's not easy. Look here or here. the latest (stable) hibernate version does not support JPA Version 2.1. I'll have to think about how we will deal with that.
Tracy Poff wrote:So I read about this and thought some, and I wanted to ask: is there some reason why you cannot (or should not) treat these as regular database entries, just like games or release groups? Certainly there are many of these that seem like a good fit for an enum (belonging to a limited set of choices, wanting to constrain values), but it looks like actually persisting enums in the database is a lot of trouble.
On the other hand, if these data lists are instead tables with entries for each item, there shall be no trouble storing them in the database (naturally), and we get the value constraint 'for free' as well. The program code can ensure that e.g. a Release Group links to some Release Group Reason, but it doesn't actually need to 'know' anything about what they are. Too, I think that we may want to treat some of them as objects in their own right, e.g. having descriptions and other metadata. Consider platforms or media types as examples of this.
Tracy Poff wrote:I was feeling a bit industrious, today, so I threw together a prototype of the server that treats ReleaseGroupTypes as database objects, rather than enums. The branch is here, and there's a corresponding branch of the client here. Of course, it's just a very simple change that I mainly did to get more familiar with the JPA. I followed the style of the existing code, more or less. It did bring up a couple of thoughts, though.
I suppose it shall be not too difficult to replicate this experiment for the other data lists, if you think that it's suitable. I welcome any feedback on my implementation, especially since this is my first time working with databases in java.
- 1. If I did not do this in totally the wrong way, then there may be a bit of a mess, once everything is implemented--one DAO for each data list, plus one for each other type in the database. Is that right?
2. If all of these data lists are made into entities in the DB, then the JSON that we return from the server may grow to be very large. Imagine that there is a lengthy description for each release group type (or each platform, or whatever), which is then duplicated in every single release group with that type (resp. platform, etc.). Is this likely to pose a problem, do you suppose? Though maybe the server can be made to emit partial representations of some of these, or something. Or, well, bytes are cheap, so maybe it just doesn't matter.