1

the suggested_buffer_size of user.about_me is currently 3000.

it is apparent that this is the server-side field length.

the problem is that the text is stored server-side in markdown but when served is expanded to html resulting in values that exceed 3000 characters.

when persisting, depending on the consumer, this can result in truncated data or truncation exceptions being thrown from the RDBMS.

it is my experience, gained by maintaining a complete user database, that a value of 4000 for suggested_buffer_size of 4000 is safe and more accurate.

also, I would suspect the same issue would apply to post body fields including comments, though I have not gathered metrics on those fields.

Improve this question
0

1 Answer 1

Reset to default
1

Suggested buffer size is just a suggestion, you've always been required to handle larger values should they be encountered. Exactly how you do so is an [app] specific detail.

In this case, the field backing about_me on the server has been resized since the API was released. It makes about_me a more acute case, but its always been possible to craft a neurotic entry whose HTML version would be in excess of API's suggested_buffer_size for the field.

Improve this answer
6
  • i am not sure i agree with the practice of suggesting a value that is known to be insufficient. It is my experience both when writing SODDI for importing the data dump and in pulling all users that it is not uncommon for a post rendered as html to exceed these suggested values simply by virtue of using the alloted markdown characters. Unfortunately, the only way to gather these metrics is to either have access to the DB and do a metrics run, rendering all markdown fields to get an idea of what a safe margin would be or to use the API to pull all records.
    – Sky Sanders
    Commented Oct 4, 2010 at 6:56
  • maybe this is something that deserves a few hours of time on that side of the fence. When you say that we should always be ready to get more data than advertised you are saying that we should guess. and if we guess wrong, data is either truncated or exceptions occur. surely there is a middle ground.
    – Sky Sanders
    Commented Oct 4, 2010 at 6:57
  • @Sky the two options are: "a concrete number which we say will never change, ... but then we change it when forced to" or "a number which we say is a good buffer size if you're going to allocate one, but which is not guaranteed to be large enough for all values, forever." There isn't any middle ground, unless you want us to return no guidance at all. Bluntly, if you're constraining your data types to the suggested_buffer_size you are explicitly violating the API contract and that's the problem, not whether the number is a perfect indicator (we say in the name that its not!).
    – Kevin Montrose
    Commented Oct 4, 2010 at 9:04
  • 1
    +1 - IMO, it all comes down too: "its always been (and it will always be) possible to craft a neurotic entry whose HTML version would be in excess of API's suggested_buffer_size for the field"
    – Dan Dumitru
    Commented Oct 4, 2010 at 9:24
  • sure, i understand the position. curious as to how using the suggested buffer size is an explicit violation of the api contract.
    – Sky Sanders
    Commented Oct 4, 2010 at 10:12
  • @Sky - using it as a concrete limit is, using it as a default buffer size (like the name suggests!) isn't. Your original question makes it clear you want to do the former, which is a contract violation.
    – Kevin Montrose
    Commented Oct 4, 2010 at 22:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .