I am prepared to abandon this proposal, since you haven't found my arguments to be convincing. I'm not so arrogant as to think I've got the One True Solution and couldn't be mistaken, of course.
That said, I will answer your concerns, just for the sake of clarity and a sense of closure.
gene wrote:I don't agree that just because one part of an application (contribution process) is not so frequently/massively used as another part (read/display game data) it should be built as a seperate application. And as I said before, in my opinion it cannot be a criterion that one part of the application should get more stable by seperating other parts of the application from it.
I'm not sure if you're saying that you don't think that separating the application into smaller pieces will make any individual part more likely to be stable, or of you're saying that you don't think that's a good enough reason to do it. Either way, that wasn't my whole reason for wanting to separate the parts: in my opinion the moderation/contribution part is different enough from the database part that it would be rational to separate them, even absent any other benefits. I recognize that you think separating them is a bad idea, for the following reasons, among others...
gene wrote:The history of a game data set is in my opinion directly coupled with the user(s) who edited this data set. You propose that we document the metadata of data changes with a text field - no way! It must be possible to view a detailed list of "who edited what game data when" and display this data directly together with the game data. This information should in my opinion also be retrievable from the application via REST calls. Just like (nearly) every data from our application. We must be able to answer a request like "list the games that user X contributed to in the last year".
I was I guess not too clear on this, but I did imagine that the text we stored would be structured, so you could still do all that stuff, albeit with a little program logic involved rather than just a database call. I'm sure you realize that if each historical version of the 'contributing user' field contained the user responsible for that version of the thing, then we could walk through the history to pick up a list of historical contributors, together with the times of their contributions. And, naturally, if we used structured text then we could always have a SQL query with "WHERE Contributor LIKE '%<link rel="author" href="
http://client.oregami.org/user/1234">%'" or whatever to get those kinds of things. I definitely wouldn't agree with any proposal that harmed our ability to retain authorship information!
gene wrote:During the contribution process users will enter game data. This game data needs to be saved temporarily in my opinion before the contribution is finally "submitted". Just like a shopping basket in an online shop. We will offer quite complex HTML forms (game data, source infos, upload files), so the user must be able to save the game data from the current contribution. Therefore we need an implemented game data model - and not a second one, but the only one. A "moderator" has to take a look at the contribution data bevore he can approve it. Or only some parts of it. For all these things I want to build just one integrated data model - not two seperated.
I have in fact done some thinking and research on this problem before making my suggestions. See for example
this. To summarize the results of my consideration and research, for having a change moderation system, we have essentially three options:
- Store all unapproved changes as extra rows in the regular table. Add columns to show the state of each row as either approved or in some stage of the contribution process. Remove old rows from the table when new ones are approved or else have a marker for deprecated rows. I didn't like this idea very well--seems ugly and inelegant and requires us to be quite careful to make sure we're tracking state correctly.
- Duplicate every table so as to have 'pending' tables, and copy data over when approved. This is a lot like the first method, but I like it a little better--the logical separation should make things simpler.
- Invent a simple language to describe changes to database tables, and create a single new table to hold all pending changes. If we were sending changes over HTTP as JSON anyway, we don't even have to invent a new language--just store some metadata and the JSON data we'd be sending, and then send it over once approved. This was my preferred method, which led to my suggestion.
gene wrote:For maintenance purposes we may always use HTTP techniques - just add a new server instance and then turn of the old one - like a load balancing server. One
may divide an application into two applications for that - if there were no other reasons for not doing this. But I think there are reasons why we should not make two applications.
Do you still want to convince me?
Well, like I said, I've spent enough words trying to convince you, and I don't think I'm likely to. You have a preference against splitting programs up, and I have a preference for splitting them up, and I guess neither of us will convince the other to change sides. So, unless this post has caused you to have a change of heart, I guess we should just consider this a rejected proposal and be done with it.
The next step, I think, must be to decide how we're storing the unapproved changes. I outlined my thoughts above, but maybe you have a better plan. I'm sure that we should have a new thread for these discussions--I'll leave it to you to create it, if you will.
