VArraySet.Lookup Re: How to sort b sequence? FW: Order of returned VArraySet rids when using FindLinked with a VArraySet arg.

[Ed Kleban]

On 12/15/05 4:16 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 12/15/05 3:38 AM, "Ed Kleban" <Ed at Kleban.com> wrote:
>   
>> What I would like to then do is:
>> 
>>     // Sort records by sequence number:
>>     orderedTreeRidSet = TblTree.Sort( treeRidSet, TblTree.fTreeSeq )
> 
> MISTAKE!
> 
>     treeRidSet -- is set of records for table TblItems.
> 
> So you cannot use it in TblTree.Sort()
>    
>> 1) Do all this much more slowly in SQL.  Yuck.
> 
> I think this is only a way until we give you power of BinaryLink Ordered
> 

Yeah, but Ordered BinaryLink (OBL?) is not something that you want to rush.
This needs a lot of thought, coding, testing, and beta testing before it
you'll want to make this available.
 
>> 2) Combine the TblTree fields into TblItems where I have a sufficent set of
>> API calls to make this work... But now that TblTree is managing MANY:MANY
>> parent/child relationships his just isn't feasible.
> 
> right
>  
>> 3) Convince to you write ASAP a FindLinkedAsArraySet method that preserves
>> the same order of records in the VArraySet result as the same order in the
>> passed inSet argument.

This on the other hand would be a simple minor tweak to existing code, and
is the topic of other email we are exchanging.  Being able to do something
sooner like this would be great.

> 
> You have see mistake above?
> 
> So you need do 2 such conversions.
> 
(1)  >     find items
(2)  >     convert to tree
(3)  >     sort
(4)  >     convert to items

If you implement FindLinkedAsArraySet with the optional:
   ( inRetainedRid as EVRetainedRid = kLinkedTo )
parameter as I proposed, then this will take care of both
(1) and (2) together.

The simple, fast, one-line, generalized call to sort I note above can then
be used.

But you're quite correct that we still need to do a conversion for (4).
And if you choose not to implement inRetainedRid then yes, we need to do a
conversion for (2) as well.

And this conversion is very messy.  As I noted, the code I used for it was:
 
> 4) Ok, I figured out one possible way out of this predicament.   You can
> execute a loop to replace every TblTreeRid in orderedTreeRidSet with the
> corresponding TblItemRid from the same record, then return the
> orderedTreeRidSet (which is then actually an orderedItemRidSet ):
>   
>   call cursorOnFTreeChild.updateFieldCursor
>   for index as Integer = orderedTreeRidSet.count downTo 1
>     treeRid = orderedTreeRidSet.itemAt( index )
>     orderedTreeRidSet.ItemAt( index ) = _
>         cursorOnFTreeChild.integerValue( treeRid, kNoUpdate )
>   next
>   
>   return orderedTreeRidSet

Having to perform a loop with a get and set for each element of the ArraySet
would of course be much faster if there was an API call that did this.  More
importantly, it could avoid the problem regarding lack of a lazy read that I
compensate for through the use of one of my magic cursorFields, but which
many folk don't even realize is a problem that they are paying a huge
performance penalty for.

So how about a quick and simple API call for performing this mapping
function?  

Perhaps something like:

=======

VArraySet.Lookup( 
    sourceSet as VArraySet,
    fromField as VField,
    targetSet as VArraySet = nil)

    Retrieves the value of fromField out of the records with RecId
    values included in sourceSet, and stores the retrieved values in
    the corresponding item of targetSet.  When targetSet is nil or when
    sourceSet = targetSet, then the values of sourceSet are replaced
    with the retrieved field values from the records that sourceSet
    identifies.

    Note that fromField must be a numeric field.
    
    If sourceSet has fewer items than targetSet then only the first
    sourceSet.count items of targetSet are affected.  If sourceSet has
    more items than targetSet, then additional items will be appended
    to targetSet.

=======

Note that I endeavored to specify a more generalized method here than is
necessary for my immediate needs.  The targetSet parameter could certainly
be omitted in a quick and dirty implementation to keep things simple until
some later more comprehensive version can be made.

Also note that in an even more generalized version that sourceSet could be a
VBitSet when targetSet is not nil -- which I suspect would also be very
useful to some including myself sooner or later.



> 
> Now tell me, that BinaryLinks with order beat
> ANYTHING that RDBMS world can offer :-))
>