Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Is there a list of the constraints that the various graph API fields adhere to? For example, I know that a Facebook User ID is a 64 bit integer.
I’m currently creating a MySQL table to store request ids. But I don’t see it listed anywhere whether this needs to be a 64 bit or a 32 bit number. So that’s the immediate question but a more general resource would be helpful.
Good question. I have struggled often with what are the right formats to store these. The option that is expected to give you least maintenance issues is to use a VARCHAR since even if FB changes the format, you are still well covered. And since there is little possibility of range queries on request ids, there is little concern there.
Of course, the biggest issue with using VARCHARs is that it is not optimal for a storage/query comparison perspective.
Additionally, all Facebook Objects (Users, Pages, Requests etc) all seem to have unique integer identification, as visible by hitting id”>https://graph.facebook.com/id, and hence using a number is probably a pretty safe option.
If you are not expecting to store millions of request_ids, I would say play it safe and put them into VARCHARs. If not, go with a number of appropriate length.