Grouper Developers Forum

[Shilen Patel <>]

All the searches would be substring searches (middle matches).  That 
would keep the UI simpler.  Though if we want to have exact match 
searches or match the start of a string (now or in a future release) we 
can add indexes for the search columns.

I believe indexes on the sort columns should help in some cases.  For 
instance, if you're sorting and paging at the same time.  Though if we 
find out that the benefit is small and folks would rather save the 
database space, we can leave them off.

Thanks!

-- Shilen


On 3/30/11 11:07 AM, Jim Fox wrote:
> I don't understand the indexing.
>
> I guess it's thought that searches are often middle matches (like '%xxx%') and
> an index is no use, but often a search is on the start of a name (like 'abc%')
> and an index would be very helpful.
>
> Why would there be an index on sort strings?  Do databases use column indices 
> when
> sorting a retrieved set of records?
>
> Jim
>
>    
> > I've updated the wiki page after talking to Chris last week.  Let me know if
> > there are anymore comments.
> >
> > https://spaces.internet2.edu/display/Grouper/Member+search+and+sort+columns
> >
> > Thanks!
> >
> > -- Shilen
> >
> >
> > On 3/25/11 11:03 AM, Shilen Patel wrote:
> >      
> > > Hi Chris,
> > >
> > > I had assumed that the values in the sort and search columns would be
> > > attributes, but it would be flexible since you can make virtual
> > > attributes in the sources.xml file.  Is there a reason not to make them
> > > all attributes?  Do they need to be marked as "internal" somehow so they
> > > don't get seen anywhere else?  So this would work for g:gsa for instance:
> > >
> > > <init-param>
> > > <param-name>subjectVirtualAttribute_0_attr0</param-name>
> > > <param-value>${subject.getAttributeValue('name')},${subject.getAttributeValue('id')},${subject.getAttributeValue('displayName')},${subject.getAttributeValue('description')}</param-value>
> > > </init-param>
> > > <init-param>
> > > <param-name>searchAttribute0</param-name>
> > > <param-value>attr0</param-value>
> > > </init-param>
> > >
> > > That way, each of the search columns (for both people and groups) can be
> > > either a single attribute or multiple attributes delimited by
> > > something.  For your case with a single search box that maintains
> > > security, there could be an API method with a boolean
> > > useDefaultSearchCol and a config option that lists the order.
> > >
> > > search.defaultIndexOrder=2,1,0
> > >
> > > So if you have access to the first one (searchString2), then that would
> > > be used.  Otherwise, try the next and so forth.  searchString0 would be
> > > the most public.
> > >
> > > Maybe a config option for default sorting as well..
> > >
> > > sort.defaultIndex=0
> > >
> > > And yes, sorting using a sort column should exclude results that have a
> > > null value for that column.
> > >
> > > Thanks!
> > >
> > > -- Shilen
> > >
> > >
> > > On 3/24/11 11:02 PM, Chris Hyzer wrote:
> > >
> > >        
> > > > I wonder if there should be a method in the Source interface which
> > > > customizes things.  For example, for groups, it isn't really configured in
> > > > the sources.xml which attributes there are, and for the search string,
> > > > maybe someone wants in one col: group.name, group.id, group.displayName,
> > > > group.description.  for the jdbc2 source, there is no attribute for
> > > > lowerSearchCol, but there is a column for it, maybe it can be used somehow
> > > > without being a subject attribute with some Java magic in the Source
> > > > class.
> > > >
> > > > Also, I would think the first sort/search slot should have something for
> > > > every source as a requirement, so when you do a normal search and sort
> > > > where the user didn't select a special sort, the results will be sorted.
> > > > i.e. for groups maybe ththe sort should be displayExtension or
> > > > displayName.  Also the first slot should be public (note groups are also
> > > > filtered for view privileges somewhere along the line).
> > > >
> > > > In the case you outline, if the default sort is on the screen, and someone
> > > > clicks to sort by last name, would group source members not show up since
> > > > they do not have a sort value, or would they be last and unsorted a the
> > > > end of the list?  I would think we would want them not to show up, right?
> > > >
> > > > Finally, for the search col, do we have multiple columns for security or
> > > > for ease of search.  As I mentioned on the call, I pictured it as being
> > > > for security.  If you look at the simple membership update screen
> > > > (attached), there is a find member of group combobox.  This is not a
> > > > complex form where you search for attrX=val1&&    attrY=val2...  Anyways,
> > > > some admin users could search on everything about a person.  People
> > > > affiliated in a certain way at Penn could be other attributes (i.e. in the
> > > > online directory is the name of a student displayed in the public view of
> > > > the directory the same way as it is to someone authenticated with the
> > > > university).  Then there is the public view which has a different list of
> > > > attributes to search on.  Just trying to keep the configuration, the UI,
> > > > and usability simple here... :)
> > > >
> > > > Thanks,
> > > > chris
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: 
> > > >
> > > > [mailto:]
> > > >  On Behalf Of Shilen Patel
> > > > Sent: Thursday, March 24, 2011 4:47 PM
> > > > To: Grouper Dev
> > > > Subject: [grouper-dev] search and sort columns on member table
> > > >
> > > > To follow up on an action item from the last call and continue the
> > > > discussion on search/sort strings, here's a wiki page.
> > > >
> > > > https://spaces.internet2.edu/display/Grouper/Member+search+and+sort+columns
> > > >
> > > > Feel free to make edits or add comments.  Let me know if there's a use
> > > > case that will not work with this design.
> > > >
> > > > Thanks!
> > > >
> > > > -- Shilen
> > > >
> > > >
> > > >          
> > >        
> >
> >