I've so far only found use for it in lookup-columns, but different people, different needs.
If want to make a pipe-separated lookup-column of values like these: subject(string), ranking(number), previous_ranking(number), posted(date), modified(date)
You can combine values of the same data-type under one @Text like this:
@Implode( subject :
@Text( ranking : previous_ranking ) :
@Text( posted : modified ) ; "|" )
Apart from a timesaver, I also find it easier on the eye, than:
@Implode( subject :
@Text( ranking ) : @Text( previous_ranking ) :
@Text( posted ) : @Text( modified ) ; "|" )
Or, even worse:
subject + "|" +
@Text( ranking ) + "|" + @Text( previous_ranking ) + "|" +
@Text( posted ) + "|" + @Text( modified )
3 comments:
While I agree, the problem is that the last is simply more efficient. Or at least, it used to be. This might have changed in the @Formula rewrite in ND6.
The problem is that the memory allocation needed for those various list concatenations is larger than the simple text conversion and string concats. There's a lot more array movement apparently going on in the former techniques.
Again, this may have changed in the post-6 world. I forget what the details were.
I would think that the column-values are computed every time the index is updated..?
For applications with few changes/ 5-10 000 documents, I shouldn't think you would notice any difference.
If you have an application with many documents, where the index is updated several times an hour, the "ugly" code is probably the only valid solution.
The problem is (or was) with the way Notes did list concatenations, which - when written literally like "a":"b":"c": ... used to be "very slow".
"Very slow" by @Formula standards, that is, which most of the time makes it still more than fast enough. In Notes 6 and up, performance of adding new list elements has been improved around 50%, although it's still slower than many other operations in @Formulas.
Damien Katz has blogged about what he did in his rewrite of the formula engine. I think the posting was titled "formula languages dirty secrets" or something like that. personally, I would probably not care too much for performance issues here in most applications.
Post a Comment