Oregami Forum

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.

• 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.

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.

• we should create a base class for data list types with a field "value" (that would replace your name)
• every data list class extends from this base class and has no further own attributes but only the inherited ones
• we should create a constructor with (Long key, String value) to create these central data list instances with a predefined key.
• to fill in values we could the do this:
  Code: Select all

  	private void addReleaseGroupTypes() {		
  		rgtRepository.save(new ReleaseGroupType(ReleaseGroupType.ORIGINAL, "Original"));
  		rgtRepository.save(new ReleaseGroupType(ReleaseGroupType.ENHANCED, "Enhanced"));
  		rgtRepository.save(new ReleaseGroupType(ReleaseGroupType.DEMO, "Demo"));
  		rgtRepository.save(new ReleaseGroupType(ReleaseGroupType.REMAKE, "Remake"));
  	}

  with something like this in the data list class:
  Code: Select all

  	public final static Long ORIGINAL = 1L;
  	public final static Long ENHANCED = 2L;
  	public final static Long DEMO = 3L;
  	public final static Long REMAKE = 4L;

  This would assure that these values don't change over time (old data will stay consistent)

gene wrote:we should create a base class for data list types with a field "value" (that would replace your name)

gene wrote:every data list class extends from this base class and has no further own attributes but only the inherited ones

gene wrote:we should create a constructor with (Long key, String value) to create these central data list instances with a predefined key.
to fill in values we could the do this:

Code: Select all

	private void addReleaseGroupTypes() {		
		rgtRepository.save(new ReleaseGroupType(ReleaseGroupType.ORIGINAL, "Original"));
		rgtRepository.save(new ReleaseGroupType(ReleaseGroupType.ENHANCED, "Enhanced"));
		rgtRepository.save(new ReleaseGroupType(ReleaseGroupType.DEMO, "Demo"));
		rgtRepository.save(new ReleaseGroupType(ReleaseGroupType.REMAKE, "Remake"));
	}

with something like this in the data list class:

Code: Select all

	public final static Long ORIGINAL = 1L;
	public final static Long ENHANCED = 2L;
	public final static Long DEMO = 3L;
	public final static Long REMAKE = 4L;

This would assure that these values don't change over time (old data will stay consistent)

gene wrote:I also tried to create some JUnit tests with JPA persistence, but I did not succeed. We should try to accomplish this to test our code.

Tracy Poff wrote:Just to be clear, your only reason for this is to ensure that keys stay consistent? Because a major benefit of storing these in the database only is that no code changes are necessary on the server when we add new items to the data lists, and we'll lose that, if we do this. I think that the only time a key would change is if the database were wiped and things were re-inserted (i.e. not a database backup/restore), which is happening right now during development, but should never happen during production.

Could you expand a little more on this issue?

gene wrote:Besides I changed the CascadeType for the field Game.gameEntryType from "ALL" to "none" (just deleted the ALL).
Only this way if a Game is deleted the associated GameEntryType stays in the database.

gene wrote:This pattern should work for all DataLists, so we can now proceed to fill in all DataList fields from our data model.

Tracy Poff wrote:Although of course the data lists can be added independently of the rest of the data model, do you think that we should try to go through the whole data model and figure out what's 'final' and what still needs further discussion? It'd be good to review everything and see how mature our data model is, at the moment, I think.

MZ per X wrote:I'd rather go a different way, and use development sprints like gene suggested some time ago. Discussing the whole data model to the bone is not worthwhile, since some parts are still missing, and the real detailed questions come up in development only.

In a development sprint, we could specify the exact features we want to implement next, finalize the theoretical data model for these, draft the UI, then code and test it. This way, we could work on digestible pieces, and see results in reasonable time.

Tracy Poff wrote:Could you please explain how the benefits of using constants this way will outweigh this drawback?

gene wrote:During development I would like to have some date of games with which I can "work" (mainly display, later edit). The way I chose to satisfy this need is the class "DatabaseFiller", which (how surprising) fills the database with some useful data. For this I do need some "reference" to reference the single values of the DataLists. We may alternatively choose the text, but that basically would have the same drawbacks.

gene wrote:On the other hand if we may want to distinguish betwenn concrete values of a data list inside the code we do need some reference. And as the key of a productive data list entry will stay constant, why should we not write them down in the code to be used there? I am used to this pattern from different projects at work.

gene wrote:Yes, with "CascadeType.ALL" if I deleted a Game object in a unit test, the referenced GameEntry was also deleted. You may test this locally.

gene wrote:Well, what now (if we decided to leave things as they are right now)?
One pattern that is "open" are "tag lists", that would be "ManyToMany" relation. But I think that the "tags lists" are very similar to "data lists".

gene wrote:We could then try to build a basic part of the data model and then think about other things (authentication e.g.).

Tracy Poff wrote: If we're wanting to do something with some particular data list values that the client won't know to send (say some filtering because a keep case has a spine but a paper slipcase does not), then that may be a case where our data model needs to be expanded to include that information. But given the choice, for sure I agree we'd do better to use the defined constants than just the text strings or whatever.

• GameEntryType
• ReleaseType
• ReleaseGroupReason
• DemoContentType
• and some more

• every type needs an own implementation of the DAO class
• the method "findByName" is implemented in every DAO
• and some more details. But it's an improvement!

    {
        "id": 1,
        "version": 0,
        "lastUpdate": null,
        "gameEntryType": {
            "id": 6,
            "version": 0,
            "lastUpdate": null,
            "value": "GAME"
        },
        "gameTitleList": [
            {
                "id": 3,
                "version": 0,
                "lastUpdate": null,
                "title": "The Secret of Monkey Island"
            },
            {
                "id": 1,
                "version": 0,
                "lastUpdate": null,
                "title": "Monkey Island 1"
            },
            {
                "id": 2,
                "version": 0,
                "lastUpdate": null,
                "title": "Monkey Island"
            }
        ],
        "releaseGroupList": [
            {
                "id": 1,
                "version": 1,
                "lastUpdate": null,
                "name": "DOS-Demo",
                "releaseGroupReason": null,
                "releaseType": {
                    "id": 1,
                    "version": 0,
                    "lastUpdate": null,
                    "value": "NATIVE_DEVELOPMENT"
                },
                "demoContentTypeList": [
                    {
                        "id": 3,
                        "version": 0,
                        "lastUpdate": null,
                        "value": "CONTENT_LIMIT"
                    },
                    {
                        "id": 7,
                        "version": 0,
                        "lastUpdate": null,
                        "value": "TECH_DEMO"
                    }
                ],
                "censored": false,
                "released": true,
                "system": "MSDOS",
                "unreleaseState": null,
                "releaseList": []
            }
        ],
        "mainTitle": "The Secret of Monkey Island"
    }