I'm pretty sure the current max size for the change info (not the individual 
fields, but the aggregate) is 65k.

-- Paul
________________________________________
From: Chris Clark [chris.cl...@ingres.com]
Sent: Monday, November 23, 2009 4:44 PM
To: reviewboard@googlegroups.com
Subject: Re: fields_changed in changedescs_changedescription

Christian Hammond wrote:
> We've done a little bit of testing with the server at VMware. There
> seems to be a mix. We've had people try to dump ~1MB log files in for
> Description and for Testing Done. Our Review Board admins there are
> beating people over the head now to stop doing that, but given that
> we're seeing even that usage, we'll need to come up with a decent
> limit there.

Crumbs! 1Mb seems a little excessive for "here is what I changed" or
"here is how I tested it". I'd hazard a guess these are test
results/scripts. Results and test harnesses could be great to add as
attachments which can then be downloaded by interested reviewers. I
think you mentioned this may be a 1.2 feature?

> Oh, and one thing I forgot about... We store the before and after of
> each field. So it's not ~50/50 for testing done and the description in
> the change information. It's more like 25/25/25/25.

Even smaller, oh well there is always gzip ;-)

Which objects are we talking about here? Is it the table
"changedescs_changedescription" with column "fields_changed"? This could
be mapped to a CLOB so we are talking a total of 2Gb bytes for most
storage engines, there shouldn't be a noticeable limit for most back
ends! Hazarding a guess are you seeing problems with MySQL as the
backend? Changing the back-end OR the datatype mappings would be an
"easy" fix here.

Speaking for my users I think we could live with a 64Kb (possibly 32 and
at a push 16Kb but I'd be unhappy about 16Kb) limit on those fields. 1Mb
seems excessive but it is sort of understandable with the lack of
(arbitrary) attachment support. Having some metrics on what is in the
review database now would make a decision for a cap easier to justify
though.

Here is a quick select (didn't have time to use Django management shell)
on my reviews database (hopefully I got the correct tables):

    select max(length(description)) from reviews_reviewrequest;
    47812

    select max(length(testing_done)) from reviews_reviewrequest;
    1593


The large description length from above had the results from a test
harness, ignoring that one review:

    select max(length(description)) from reviews_reviewrequest where id
    != 867;
    21541


Hope this helps,


Chris

--
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Reply via email to