Question

I was unable to locate variable for establishing a incremental counter that could be used as a unique identifier for documents. Basically I want to create a template that will automatically assign a document number for each new document created using the template.

Thanks for your help.

Will

• TWiki version:
• Web server:
• Server OS:
• Web browser:
• Client OS:

-- WillThomas - 26 Nov 2002

Answer

See sample app Sandbox.ChangeRequest, it does what you need using the SpreadSheetPlugin.

-- PeterThoeny - 27 Nov 2002

Peter's app is quite a cool demo, didn't realise you could do this with the SpreadSheetPlugin and hidden tables - however, this approach doesn't guarantee uniqueness. If two people load that page at the same time, or a cached page is used twice by a single person, the 'next number' will duplicate a number used earlier. I just tested this with OperaBrowser and found that the 2nd change request with the same number over-wrote the original change request.

What's really needed is to have some sort of locking of a single page (or DB record) that contains the next number. This needs to be done in server side code (could be in DefaultPlugin perhaps, or a dedicated plugin) to avoid caching issues. If there is no concurrent usage, it might be feasible to use this approach and disable caching using BrowserAndProxyCacheControl techniques - but some browsers, e.g. Opera, cache very aggressively and might defeat this.

In SQL, you would do something like update countertable set nextval=nextval+1, then select nextval from countertable, assuming a single row in countertable. The important thing is that the application should really keep the counter table exclusive-locked until the change request is saved (i.e. the next value update/select and the change request insertion are a single DB transaction).

I'm not sure how you would do this using TWiki topics alone - you might be able to have a NextValue page, like the countertable above, but you would have to make sure its lock was released only after the change request was created. If there is quite a high volume of people doing this, a DB approach is better, to avoid long waits for the lock on this page.

-- RichardDonkin - 29 Nov 2002