CodeStore.net comments on "Document Action Logs, Including "Limitless" User Comments"

Reply from Tim Bunning

Tim Bunning — Wed, 02 Oct 2013 04:15:21 -0500

A) There's no mention of Rich-text as a limitless log. This can be made to look pretty and virtually unlimited, but a PITA sometimes.

B) You can 'archive' blocks of text off the list when you get to some limit, say 10k, either by deleting the last n entries or even removing element by element depending on the date.

C) You can push comments/logs out to separate docs and look them up on the 'host' doc or embed a single-category lookup. Granted loads of overhead, but helps avoid limits and possibility of rep/save conflicts.

Oh, and by the way, the '^^' delimiter can be a bit limiting, ok for @word, but @explode only uses a single character. If you want to avoid the possibility of a typed in char, use an 'alt-key number combination' to use a non-keyboard character.

Reply from Jerry Carter

Jerry Carter — Fri, 27 Sep 2013 10:31:05 -0500

Agreed - seems like I've had the luck way back to have customers who feel like they need looong history sections in their documents, so the relational model is one I pursued early on when embedded views became available on the Notes client. A bit trickier on the web than that but not so bad these days with all the options.

Reply from Lionel Conforto

Lionel Conforto — Thu, 26 Sep 2013 15:20:10 -0500

Brilliant ! Thanks for having shared

Reply from Bjørn Cintra

Bjørn Cintra — Wed, 25 Sep 2013 13:44:47 -0500

Serialize as JSON into a MIME field, pull in using AJAX and Javascript templates is a good solution, however pulling out specific items, or searching for log entries becomes harder. However unless you have many entries pr document, it is not an issue to fetch it all in one go, and hide the extra data until you need it.

In my application, I have need to store all changes (and also deletions) in all or selected fields, and to be able to search and find these when questions (often from a customer) arise. The only "limitless" option is to store each entry as a separate document, and pull them in using AJAX. This keeps the content documents "clean".

Reply from Jake Howlett

Jake Howlett — Wed, 25 Sep 2013 07:44:57 -0500

Note this page's title has the word "Limitless" inside quote marks ;-)

The limits of the Computed Value would be met way, way before the limits of the number of fields allowed.

For the case(s) I've used the above approach in they'll never get close to either limit (touch wood).

Thanks for the MIME idea. I hadn't thought of that as an option. Should work in LotusScript too.

Reply from Tim Tripcony

Tim Tripcony — Wed, 25 Sep 2013 07:40:17 -0500

NSF still has a limit on the total number of unique item names in a database. By default, it's 64KB for the sum total of all item names, so you'd still be limited to ~4000 comments per record (subject to how many "normal" items the app has). You can set the "Allow more fields in database" option in the database properties to bump this limit up to 22,893. It's unlikely that you'd get 23K comments on any record, so while it's still theoretically finite, in practice, it would almost certainly be enough. Keep in mind, however, this limit is based on item names across the entire NSF, not per note. So if you use this approach for 10 different features in the same NSF with different naming conventions for the incremented item names, you're limited to 23K for the sum total, so on average, each would be limited to ~2K, and a single document that contains a disproportionate number of items, that reduces the limit on how many items any future documents of a different type can store. In practice, again, you're rarely going to hit that limit, but it is a finite limit. The closest I've found to a truly limitless storage mechanism in NSF is MIME... which, now that Domino is so Java-centric, turns out to be a perfect container for serialized Java object hierarchies (or even just single objects). If you're interested, take a look at the work Jesse Gallagher did in this area:

http://www.openntf.org/p/mimeDominoDocument%20Data%20Source

That implementation is XPage-specific, but there's no reason you couldn't take the base techniques from it and apply it within a Java agent.