Welcome, Guest. Please Login
Tinderbox
  News:
IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).
  HomeHelpSearchLogin  
 
Pages: 1
Send Topic Print
Achieving effect of a "lookup" function (Read 4342 times)
Sumner Gerard
Full Member
*
Offline



Posts: 359

Achieving effect of a "lookup" function
Apr 10th, 2013, 1:27pm
 
I often work with notes holding "core" information that is (relatively) static plus other more volatile data that is usually imported.

Here's a simplified example. $MyString is relatively static. But $MyNum changes often.

Let's say I have a "Main" container with:

$Name       $MyString                  $MyNum     $UniqueID
EntityA     Observations.                 8          X01X01
EntityB     Other observations.          15          X03X03
EntityC     Yet other observations.      12          X02X02

I can "spreadsheet import" notes with new values for $MyNum into an "Updates" container that look like this:

$Name       $UniqueID    $MyNum  
Somename1   X01X01          10
Somename2   X02X02          20
Somename3   X03X03          17

How do I then update the $MyNum values for the notes in "Main"? I'd like the result in "Main" to be like:

$Name       $MyString                $MyNum      $UniqueID
EntityA     Observations.                10      X01X01
EntityB     Other observations.          17      X03X03
EntityC     Yet other observations       20      X02X02


This, of course, is easily done via a "lookup" function in a spreadsheet or a "join" of tables in a relational database. What's the Tinderbox way? From this thread I'm guessing it may involve find() and this and/or that and that it's probably not hard at all. I think I even saw a demo of something (perhaps) similar way back in the mists of time. But that's as far as I can get. Appreciate help!
Back to top
 
« Last Edit: Apr 10th, 2013, 2:58pm by Sumner Gerard »  
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Achieving the effect of a "lookup" funct
Reply #1 - Apr 10th, 2013, 2:57pm
 
To restate the question (lest I've misunderstood): you want every child note inside container "Main" to set its $MyNum value to the $MyNum value of a note in "Updates" that shares the same $UniqueID? Assumption: only one note within "Updates" uses a given $UniqueID. For this I'd use an agent.

Query:  inside("Main")
Action:  $MyNum = $MyNum(find(inside("Updates") & $UniqueID==$UniqueID(that)))

We use 'that' as we want the in-scope agent alias' $UniqueID to be tested against those of any note meeting the first part of the find query. In such a context 'this' would use the value of the note being tested.

You could use a rule, but I figure it's easier to set up an agent, run it after imports then turn it off. This saves either running $Rule code when you don't need to, or, fiddling with stamps to set/unset $Rule code when needed.

Sorry: code above isn't tested - I'm busy packing, as off to TB w/e early tomorrow.
Back to top
 
« Last Edit: Apr 10th, 2013, 2:58pm by Mark Anderson »  

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
Sumner Gerard
Full Member
*
Offline



Posts: 359

Re: Achieving effect of a "lookup" function
Reply #2 - Apr 10th, 2013, 3:10pm
 
Thanks for the quick response. Yes, only one note within "Updates" has a given $UniqueID. I can follow the logic of the agent action. On my machine I haven't gotten it to actually work yet (after 5 min of trying) but will experiment. Say hello to San Francisco!
Back to top
 
 
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Achieving effect of a "lookup" function
Reply #3 - Apr 10th, 2013, 3:16pm
 
I'd try using the find() as a $Rule on a test note. It may be that this is a step to far and doing the find() as an attribute expression reference is too much in one leap. A tear-down $Rule:

  $MyString = find(inside("Updates") & $UniqueID==$UniqueID(that));
  $MyNum = $MyNum($MyString);

I hope that makes sense. Our assumption mean the find() can (should!) only return one path. Inspecting $MyString will show if you get one path, a list, or nothing!
Back to top
 
« Last Edit: Apr 10th, 2013, 4:04pm by Mark Anderson »  

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
Sumner Gerard
Full Member
*
Offline



Posts: 359

Re: Achieving effect of a "lookup" function
Reply #4 - Apr 10th, 2013, 4:03pm
 
After experimenting in a test note and then going back to the agent, it turns out both ways (the original one-expression suggestion and the two-step tear-down) work fine!

For me this has the unexpected added benefit that, while only one note in "Updates" will have a given value for $UniqueID,  I can (as I often do in practice) have more than one note in "Main" with that value in the corresponding attribute (there not actually called $UniqueID) and this will update all the relevant notes in "Main."  

It really is like a lookup function, with an effect similar to setting up a one-to-many relationship between tables in a relational database.  Had no idea this kind of thing is so easily accomplished in Tinderbox. Thanks!
Back to top
 
« Last Edit: Apr 10th, 2013, 4:04pm by Sumner Gerard »  
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Achieving effect of a "lookup" function
Reply #5 - Apr 10th, 2013, 4:09pm
 
Great, glad that worked.

For later readers, I hope the tear-down is also a useful example about how to unpack a complex bit of action code if it fails to work at first and thus get a fix on where the 'failure' is occurring. One further tip, if it's still not working, go build a very simple text in a new file. for instance (though not the case above) this code might have failed as some notes either matched no $UniqueID or more than one. It's all to easy to make an assumption without actually back-tracking to see if things are as you presume them to be! That's a mistake I can certainly admit to.
Back to top
 
 

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
Pages: 1
Send Topic Print