![]() |
|
|
#1 | ||||||||||||||||||||||||||||||||||||||
|
Head Coach
Join Date: Dec 2002
Location: Maryland
|
Player database ID Jump
I just noticed this in FOFL even though it happened last year.
Why the jump in generated ids? I mean, I get that 32767 is the upperbound for a signed SMALLINT. But first, these I imagine shouldn't be signed to begin with (I don't imagine an ID would ever be negative), and I'd also think that the ids wouldn't be SMALLINT (and as they continue above 65535, they can't be). So...what exactly is going on here? I mean, I'm not sure it really matters, other than the fact that the player ids will hit six digits a wee bit faster than I anticipated they would. At least, I hope that's the only effect.
__________________
null Last edited by cuervo72 : 08-24-2012 at 11:32 PM. Reason: not seven digits, six digits. |
||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
#2 |
|
Morgado's Favorite Forum Fascist
Join Date: Oct 2000
Location: Greensboro, NC
|
Verified this against the PFL database (the largest online one I know of). Checking a SP league now...
__________________
The media don't understand the kinds of problems and pressures 54 million come wit'! |
|
|
|
|
|
#3 |
|
Pro Starter
Join Date: Oct 2000
Location: Cary, NC
|
This may be related to the transaction amount discrepancy we found earlier. I am not convinced FOF writes a true INT32, it's like it writes two signed INT16s and does the shifting or calculations internally somehow, and since they are unsigned numbers you ignore the upper bit of the lower two bytes. Perhaps a harkening back to the 16-bit days, some artifact in there. I could change everything to read it that way (and I already fixed the profit/loss income fields I believe), but with some like playerID it really doesn't matter, it's still a unique ID.
__________________
-- Greg -- Author of various FOF utilities |
|
|
|
![]() |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |
|
|