AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080530153228.5500fed7@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<chris.vandever@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E03E9A8B8@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 30 May 2008 15:36:35 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Chris Vandever" <chris.vandever@onstor.com>
Subject: Re: please review 29293
Message-ID: <20080530153635.6c314b8a@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E03E9A8B8@onstor-exch02.onstor.net>
References: <20080530103130.7aee04b7@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E03E9A8B8@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 30 May 2008 14:57:15 -0700 "Chris Vandever"
<chris.vandever@onstor.com> wrote:

> Okay, let me first say that this entire idmap thing is an incredibly
> inefficient way to create an ordered list of children, which the
> clusDb doesn't support, although it could have been made to do so.
> Then, let me say that however we resolve this we need to make sure
> all this horseshit about pages and cursors that the webUI forced into
> the CLI stays contained in the CLI.  But, spilt milk and all that...

Is that where the 'page' thing came from?  The cursor thing doesn't
have anything to do with the webUI, although the term is often used in
connection with GUIs.  The way I've changed things, the webUI asking
for page this or that is potentially much more efficient as it only
fetches up to the end of the page from the clusterdb, instead of
everything it can get for each and every time it asks for another page.

I'm just thinking ahead here in terms of cougars being able to support
a larger number of clients/users and so the max_idmap thing likely
needing to be raised above 999 in the future.

> I'd rework cluster_getIdmapRuleList() to take an additional "index"
> argument and leave pNumRec alone.  This would be consistent with the

That would be incompatible with existing callers, and would add no
capabilities while requiring more code to support.

> rest of the cluster wrapper functions for ID mapping.  (They really
> should take a "startRecId" arg instead.  That would be consistent with
> the underlying cluster APIs and would be infinitely more efficient.
> But, they're creating a chain of children so they can keep the chain
> ordered instead of just creating a bunch of child records for a common
> parent, which is unordered.)  The way these records are created and
> maintained guarantees there will be exactly one child record for each
> record until you reach the end of the list.  You can change the
> cluster_getChildRecords() call to only pass in space for a single
> recEntry just to be sure.  Then, you can just walk the list until you
> get to the specified starting record, and then you can start
> squirreling off the recEntries into the caller's buffer.

In essence, what you described is exactly what it does now.  I do
know the cluster_getChildRec function only ever returned one record at
a time in all my testing, but just to be sure I put that other
'mover' code in.

> ChrisV
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Friday, May 30, 2008 10:32 AM
> To: Chris Vandever
> Subject: please review 29293
> 
> OK, so I'm having trouble getting code for some of my other bugs to
> work, so I thought I would send you this for review.
> 
> This fixes 23242, and substantially reduces the number of clusterdb
> accesses from the authen-lib code that uses this same API function,
> while remaining compatible with the one other caller of this function.
> Oh yeah, and removes some dead code too.
> 
> 
> Change 29293 by andys@ripper on 2008/05/17 23:11:09 *pending*
> 
>         TED00023242 - Case 7541/ SGI Japan/ idmap list is limited to
> 511 entries
>         
>         Add the concept of a cursor to cluster_getIdmapRuleList();
>         use that to modify _idmap show_ to be able to fetch and
> display an arbitrary number of records from the database.
> Substantially reduces clusterdb accesses from some code paths in
> authen-lib. 
>         Eliminate unused cluster_showIdmapRule method.
> 
>         
>         reviewed by
> 
> Affected files ...
> 
> ... //depot/dev/nfx-tree/code/ssc-authen-lib/idmap-cfg.c#4 edit
> ... //depot/dev/nfx-tree/code/ssc-cluster/cluster-idmap-api.c#3 edit
> ... //depot/dev/nfx-tree/code/ssc-cluster/cluster-idmap-api.h#1 edit
> ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_idmap.c#5 edit
> 
