Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Brown running Grouper 1.3.0 rc1 in QA

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Brown running Grouper 1.3.0 rc1 in QA


Chronological Thread 
  • From: Shilen Patel <>
  • To: "Cramton, James" <>
  • Cc: <>
  • Subject: Re: [grouper-dev] Brown running Grouper 1.3.0 rc1 in QA
  • Date: Tue, 29 Apr 2008 12:59:23 -0400


On Apr 28, 2008, at 4:46 PM, Cramton, James wrote:

After a week of fighting other fires, I finally had a chance today to upgrade Brown’s Grouper QA environment to Grouper 1.3.0 rc1.  All in all, it went pretty smoothly, and I like the improvements to the UI quite a lot. I have a few observations on the process to share; most of these pertain to an institution upgrading a large implementation, and I’m not sure if any other institutions have taken this leap yet.  

Duke's production and test environments were upgraded to 1.3.0 rc1 over the weekend.  I was upgrading from version 1.0 so it required a full data dump and re-import using the 1.3.0 API, which was very time consuming, but for the most part went very well.  I have some other thoughts which I will explore further first.



-          I used the Oracle sql script to update the DB schema from 1.2.1 to 1.3.0; this took about 12 minutes to complete, without incident.  By my way of reading it, the DB upgrade instructions recommend adding foreign keys using the addforeignkeys ant target, but the Oracle script already added them; the ant script coughed out all sorts of errors because of this double duty. I suggest revising the documentation to be more specific about when to use the ant target vs. DB-specific scripts.

I'll make that more clear.  Thanks.





-          As a point of reference, we’ve been experimenting with performance in our system, and we have yet to find a performance bottleneck. In particular, in this build, we upped the  comparator.sort.limit in the ui/resources/grouper/media.properties file to 50,000, and we have not been able to document a significant performance hit. Our largest group contains 17,000 members, and it displays a sorted list of members within 30 seconds, even when we display all 17,000 members on 1 page.  Why someone would want to do that is unclear, but it does perform well in our system.
 


That's good to know.  I can't imagine why somebody would want to do this in the UI, but there are probably real cases using the web services interface.


Thanks,

-- Shilen





Archive powered by MHonArc 2.6.16.

Top of Page