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:
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.