Bob Balaban's Blog

     
    alt

    Bob Balaban

     

    Geek-o-Terica 13: Notes Response Hierarchies - Without Views

    Bob Balaban  December 6 2010 11:01:00 PM
    Greetings Geeks!

    So. Everyone who's written any interesting amount of LotusScript (or Java) code in Notes or Domino has done the whole "get a view, get a document, get the first response to that, travel the (possibly deeply nested) response hierarchy..." thing. Probably more than once. It can be tedious, and you often have to create special views in your app that are used only for code navigation, which can blow up the size of the NSF. Yes, you can use the NotesViewNavigator class to manage categorized and nested views, it's a great piece of functionality. However, I have found that in large databases (4gb+), with complex views, the ViewNavigator class can be pretty slow to set up and use.

    Is it possible to figure out response hierarchies without using a view at all? Yes, it sure is! You can navigate response hierarchies just using features in the NotesDocument class.

    But first you have to make sure the database itself is set up to support that. Go to the properties box, and to the "propeller beanie" tab (this screenshot is from Notes 7):

    Image:Geek-o-Terica 13: Notes Response Hierarchies - Without Views

    Make sure that the double-negative "Don't support specialized response hierarchy" is NOT checked.

    To explain how this works, let's start with the basics of response documents. A document is a response to another document (it can only be a response to one other document, or not at all) if it contains a data item named "$REF", and that item contains the UNID of the "parent" document. That's it, very simple. The parent does NOT (in the document itself) contain a list of "child" documents. When documents show up in a View that has response hierarchies enabled, the view display logic figures out all the parent/child/child-of-child relationships based purely on the $REF pointers. No special support from the NSF layer is required.

    But if you don't disable the "specialized response hierarchy" feature in your database, then NSF is also, quietly and robustly, perhaps without you even realizing it, keeping track of which documents have $REF items and to what other documents they refer. And (the important point), this information is available through the Notes C API, and, as a consequence, is also available in the LotusScript and Java Document class.

    How do you do it? Simple! Use the NotesDocument.Responses property. It returns a NotesDocumentCollection object containing all of the first-level responses to the  current document (if there are any). You can then follow the nested hierarchy (if there is one) by extracting each document object from the collection and getting its Responses list in turn.

    Not quite as convenient as using NotesView or NotesViewNavigator getfirst/getnext calls, but there are a couple of advantages to doing it this way:
       - You might be able to reduce the number of views in your NSF, which saves disk space and also results in better performance at NSF indexing time
       - If your response hierarchies are relatively simple (e.g., only 1 level of responses), this technique is quick and easy to code

    Is it for you? Only you can make that determination. Try it out and see!

    Happy coding! Geek ya later!

    (Need expert application development architecture/coding help?  Want me to help you invent directory services based on RDBMS? Need some Cloud-fu or some web services? Contact me at: bbalaban, gmail.com)
    Follow me on Twitter @LooseleafLLC
    This article ┬ęCopyright 2010 by Looseleaf Software LLC, all rights reserved. You may link to this page, but may not copy without prior approval.


    Comments

    1Karl-Henry Martinsson  12/6/2010 7:28:41 PM  Geek-o-Terica 13: Notes Response Hierarchies - Without Views

    Note that if "Don't support specialized response hierarchy" IS checked, you have to compact the database after you make the change, or it won't take effect, if I remember it correctly.

    2Bob Balaban  12/6/2010 8:42:26 PM  Geek-o-Terica 13: Notes Response Hierarchies - Without Views

    @1 - Yes, that makes sense. Thanks for the comment!

    3JJTB Somhorst  12/7/2010 2:13:54 AM  Geek-o-Terica 13: Notes Response Hierarchies - Without Views

    Hi,

    I'm wondering. When working on realy big databases would this way of using the response hierarchy's be faster then using a view where you only use the column values and dont use the document directly?

    4Rich Greaves  12/28/2010 8:48:51 PM  Geek-o-Terica 13: Notes Response Hierarchies - Without Views

    One thing to note is that you'll want to be sure to check to see if the response documents are valid. The collection returned by NotesDocument.responses will return deletion stubs so I always check that any documents in the resulting collection are vaild (doc.isvalid) and are not deleted (doc.isdeleted) before further processing. I wish I had figured this out long before I did...

    5Bob Balaban  12/29/2010 6:43:12 AM  Geek-o-Terica 13: Notes Response Hierarchies - Without Views

    Good tip, thanks!

    6Scott Leis  3/17/2011 6:20:45 PM  Geek-o-Terica 13: Notes Response Hierarchies - Without Views

    Not sure if you'll see this because I'm commenting a bit late, but Designer Help (as of 8.5.2) says this in the "Response property" topic:

    -- If the database option "Disable specialized response hierarchy information" is selected, this property returns an empty collection.

    Is the Help incorrect?

    7Scott Leis  3/17/2011 6:25:03 PM  Geek-o-Terica 13: Notes Response Hierarchies - Without Views

    Actually, never mind my last comment. It seems I misread something in the post - you're saying to make sure that option is not checked anyway.

    8Bob Balaban  3/17/2011 9:33:14 PM  Geek-o-Terica 13: Notes Response Hierarchies - Without Views

    @scott - the help is correct, the NSF-level hierarchy is not tracked if that option is checked. Score one more for confusing double-negative options...