Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] search and sort columns on member table

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] search and sort columns on member table


Chronological Thread 
  • From: Jim Fox <>
  • To: Shilen Patel <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] search and sort columns on member table
  • Date: Wed, 30 Mar 2011 09:04:48 -0700 (PDT)


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'd hope the API could be more robust.


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.

My thinking is that paging results in sorts of a only few hundred records.

Jim


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









Archive powered by MHonArc 2.6.16.

Top of Page