Thanks for the information on your server.

I agree that 1MB seems excessive, but it does make sense given the results
of test cases or tools that people may want to show. Attachment support
should help here. That is planned for 1.2. I'd see about 1.1, but I really
want to get this release out soon :)

You're certainly right about using a different column type on the database.
The trouble is that we go through Django's ORM, which abstracts the various
types. I need to see if there's a way we can override this without too much
trouble in Django. If we can map that to a much larger size on each database
we support, then we're probably good.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com


On Mon, Nov 23, 2009 at 4:44 PM, Chris Clark <chris.cl...@ingres.com> wrote:

> 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<reviewboard%2bunsubscr...@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