In my booklink tutorial app, I added a new row "isbn13" to the books table. First, this was a int(), which supports up to 10 characters only (isbn13 consists of 13 characters). As soon as I got rid of this mistake, I changed it to the next bigger integer-type: bigint(), which supports up to 19 characters.

Now I edited a book and wanted to correct the previously added isbn13-number, but it did't save this value as a 13-character long bigint. There was another, shorter number, added to the database.

In the end, I changed the isbn-table row to varchar(13) and, magically, my isbn13 codes were saved correctly.

My question: why didn't bigint() save the isbn-number? I did not write any special chars, just numbers. I checked the mysql-database with an administrative tool, it stated correctly "bigint" as the isbn13's row type there.

Well, I could fix this issue by changing to varchar(), but I would really like to know what could be the problem concerning this isse. Any ideas?

first, i would say isbn13 isn't a number, it's a string because you can't multiply two isbn's.

Right.

we type cast int's as integer's

I don't really understand this, sorry. I agree with your above statement, that ISBN-13 should be treated as string. But how would I handle it, if there would be a "real" bigint() in my mysql-table and I want to use it in my Akelos App?

we type cast int's as integer's

should be

we type cast int's as php-integer's