11 coaches online • Server time: 06:41
* * * Did you know? The best scorer is debog with 491 touchdowns.
Recent Forum Topics  FUMBBL HAIKU'S | Gnome Roster - how a... | Exempt teams |
2012-01-04 15:23:36
21 votes, rating 5
21 votes, rating 5
Note on the FUMBBL-API
Hi,
in some of my latest tools I programmed which can be used here on fumbbl, i used the API offered by Christer.
As I must recognize, the program to read certain groups (I only parse the Majors and the DFFL at this point) threw exceptions due to malformed xml.
I want to tell all the people out there what I found out so that you might be able to find the "features" a bit easier if you face the same problems:
Usually a player has an ID in form of an integer value, which is a number beginning with 0 (or 1, depends on) and each new player gets the next free number. So every player here on FUMBBL is represented by a unique number. I saw numbers higher than 8 mio, so there are a lot of players here.
- Journeyman (as a can tell so far) receive a number just like all other players.
- Mercenaries don't! They have a number that consist of "z_" in the beginning, then followed by the team's id, then ":" and the number of the mercenary the team hired (over all time) beginning with 1.
- Zombies of the good old birthday have a "z1" as id. I don't know if "z2" or "z3" exist, but at least "z1" does.
What does this mean and why do I write all this:
Usually an "id" is a number. An id that begins with a "z_" or has a ":" in it or is simply equal to "z1" isn't a number. so it is very difficult to fit those players in a database that assumes all id_s to be integer numbers. Changing the integer to a string would solve the problem but increase the time of any calculation by a huge factor. So this is not an appropriate solution. Databases need to be fast! Pages like FUMBBL or even google are not able to rely on slow databases. Searches and comparable requests would take ages instead of milliseconds.
I have to find a workaround for this now. At this point I filtered all those players out to keep the database consistent.
Perhaps this helps some of you coaches out there to find the bugs in your code. Good luck!
gan
in some of my latest tools I programmed which can be used here on fumbbl, i used the API offered by Christer.
As I must recognize, the program to read certain groups (I only parse the Majors and the DFFL at this point) threw exceptions due to malformed xml.
I want to tell all the people out there what I found out so that you might be able to find the "features" a bit easier if you face the same problems:
Usually a player has an ID in form of an integer value, which is a number beginning with 0 (or 1, depends on) and each new player gets the next free number. So every player here on FUMBBL is represented by a unique number. I saw numbers higher than 8 mio, so there are a lot of players here.
- Journeyman (as a can tell so far) receive a number just like all other players.
- Mercenaries don't! They have a number that consist of "z_" in the beginning, then followed by the team's id, then ":" and the number of the mercenary the team hired (over all time) beginning with 1.
- Zombies of the good old birthday have a "z1" as id. I don't know if "z2" or "z3" exist, but at least "z1" does.
What does this mean and why do I write all this:
Usually an "id" is a number. An id that begins with a "z_" or has a ":" in it or is simply equal to "z1" isn't a number. so it is very difficult to fit those players in a database that assumes all id_s to be integer numbers. Changing the integer to a string would solve the problem but increase the time of any calculation by a huge factor. So this is not an appropriate solution. Databases need to be fast! Pages like FUMBBL or even google are not able to rely on slow databases. Searches and comparable requests would take ages instead of milliseconds.
I have to find a workaround for this now. At this point I filtered all those players out to keep the database consistent.
Perhaps this helps some of you coaches out there to find the bugs in your code. Good luck!
gan
Comments
Posted by koadah on 2012-01-04 15:40:40
Good stuff.
Maybe it should go in the wikki
http://fumbbl.com/help:Fumbbl+API
Maybe it should go in the wikki
http://fumbbl.com/help:Fumbbl+API
Posted by gandresch on 2012-01-04 16:30:14
Sounds sensible :-)
Posted by Hitonagashi on 2012-01-04 18:07:17
Hmm.
Doesn't affect me, because I'm not tracking individual players. Very good find though, will remember that!
Doesn't affect me, because I'm not tracking individual players. Very good find though, will remember that!
Posted by Archpeasant on 2012-01-04 18:57:17
I'm not sure what you just said but GOOD JOB!
Rated six.
Rated six.
Posted by Kelkka on 2012-01-04 23:02:05
First solution i can come up with is:
when you parse the number, check if it has non-integers in it.
If it does, apply one specific number is the id (like 9999999, or -1). And if you want to keep track of those players too, strip the non-integers from the number and add that to secondary key.
This maybe isn't the most efficient but solves the problem of accidently giving id of existing or future player for merc/zombie. And you can identify each merc/zombie with the 2 keys.
when you parse the number, check if it has non-integers in it.
If it does, apply one specific number is the id (like 9999999, or -1). And if you want to keep track of those players too, strip the non-integers from the number and add that to secondary key.
This maybe isn't the most efficient but solves the problem of accidently giving id of existing or future player for merc/zombie. And you can identify each merc/zombie with the 2 keys.
Posted by DonTomaso on 2012-01-05 00:37:14
This must be important because I didn't understand it and can't see the use for it.
Rated six for intelligence.
Rated six for intelligence.
Posted by SavageJ on 2012-01-05 06:52:22
You said the reason to leave the player ids as integers in an extract is because to convert them to strings would "increase the time of any calculation by a huge factor", but these are player IDs, not actual numbers, right? So you won't be adding them together, or multiplying them, or anything like that, right? (Or will you? I don't know how you're manipulating the player data.)
Most of them happen to be integers, but identifiers are (IMHO) strings, just strings (in this case, usually) of digits.
Most of them happen to be integers, but identifiers are (IMHO) strings, just strings (in this case, usually) of digits.
Posted by Christer on 2012-01-05 10:19:50
A bit of clarification:
The normal case is that each player has an integer ID in FUMBBL. They also have a reference to a position (such as a Troll Slayer, which is also an integer in the normal case).
FFB, on the other hand, has string IDs for both players and positions. This is fine, as the integers used on FUMBBL can easily be represented by strings as well without problems.
FUMBBL simply can't store a player or position using anything but an integer. However, what you will run into during for example a birthday event is a set of virtual players on the team. These are not stored in the database, but are randomly generated in the XML API when FFB (and your scripts) access them.
Now, to implement the zombies, I had to do two changes to the API:
1. Add zombie position definitions to the roster API. These showed up with position IDs of "z1", "z2", "z3" and were always added to the roster.
2. Add up to three zombies on the teams. Since player IDs are expected to be unique, I had to make a composite ID for the player: "z_" + teamId + ":" + [1|2|3]
Essentially, if your API application doesn't care about temporary players like the birthday zombies, you can simply ignore any players / positions with non-integer IDs. FUMBBL doesn't (and can't) store those IDs anyway.
The normal case is that each player has an integer ID in FUMBBL. They also have a reference to a position (such as a Troll Slayer, which is also an integer in the normal case).
FFB, on the other hand, has string IDs for both players and positions. This is fine, as the integers used on FUMBBL can easily be represented by strings as well without problems.
FUMBBL simply can't store a player or position using anything but an integer. However, what you will run into during for example a birthday event is a set of virtual players on the team. These are not stored in the database, but are randomly generated in the XML API when FFB (and your scripts) access them.
Now, to implement the zombies, I had to do two changes to the API:
1. Add zombie position definitions to the roster API. These showed up with position IDs of "z1", "z2", "z3" and were always added to the roster.
2. Add up to three zombies on the teams. Since player IDs are expected to be unique, I had to make a composite ID for the player: "z_" + teamId + ":" + [1|2|3]
Essentially, if your API application doesn't care about temporary players like the birthday zombies, you can simply ignore any players / positions with non-integer IDs. FUMBBL doesn't (and can't) store those IDs anyway.
Posted by gandresch on 2012-01-05 11:48:39
Ignoring them is was I did :-)
I thought these were the Mercenaries ... but zombies make sense.
Thank you for the clarification.
I thought these were the Mercenaries ... but zombies make sense.
Thank you for the clarification.