GameVersion version number should be an int

[Matt Giuca]

Currently, the GameVersion class's primary key pKey is a String, which is emulating a composite key built from the Game ID (int) and version number (string). This is a bit messy, but we have decided to keep this weird string composite key.

The bug is this: The "version number" part of the string is itself an arbitrary string. It should be an int. Thus, pKey is a string comprising two ints separated by a slash.

GameVersion's version parameter should have type int. getVersion should return an int.

The reason it was a string was to support version numbers such as "1.4.2". That is not the purpose of a primary key -- they should be sequential integers which developers have no control over (they simply increment each version). Outside the scope of this bug: add another field "version_string" which is a developer-customisable version number string, for display purposes only.

[Matt Giuca (mgiuca)]

The GameVersion class now has a separate 'Integer version' field (which is persistent). This redundantly stores the version number (so a class might have pkey "42/12" and version 12). I thought we had agreed we would simply parse the integer out of the string, so it is not redundantly stored.

I'll change it so there is no explicit field 'version', and instead the getVersion method pulls the version number out of the string. Does anybody object to this change?

[Matt Giuca (mgiuca)]

Assigning back to me, to make the above mentioned change.

[Matt Giuca (mgiuca)]

Fixed in trunk r66.

[Prageeth Silva (prageethsilva)]

Oh I didn't see this mentioned comment. We have two problems with this:

a) This means the field cannot be made null when converting to the Client Model Class, but that's given we use a field. However, if the string is null, trying to get the version will given an exception. The client needs to check if the value is null, and in order to do that, the getVersion method would try to extract the value.

b) Didn't we come to the conclusion that extraction is possible only given that the data it holds is in the correct format? True, we can make sure it's stored properly, but IN CASE there is something wrong with the string, we may get an exception.

Please let me know what I should do before I can merge the data-wrapper.

Thanks!

[Matt Giuca (mgiuca)]

Re-opening this bug since apparently the fix is not acceptable. (I can't look at it now, but just making sure we don't forget.)

[Prageeth Silva (prageethsilva)]

This will be completly implemented by Tuesday (5/04/2011). There will also be a client service that lets users upload and download files.

[Prageeth Silva (prageethsilva)]

Please disregard the previous comment, it was meant to be for another bug. But for some reason it has been added to this. However, this too will be completed by the deadline (5/04/2011).

[Matt Giuca (mgiuca)]

This seems to be fixed now. Please let me know if it isn't.