On Thu, 11 Jul 2013 14:25:31 -0700, Jakob Fix <jakob....@gmail.com> wrote:
> Hi, > > we'd like to use a pre-commit trigger to validate and convert an incoming > document before storing it itself. Pre-commit to only store the document if > the validation was successful and the document was converted and stored as > expected. > > As far as I understand, CPF would be the right choice for this kind of > workflow, but it seems to only support post-commit triggers. Is this > understanding of CPF correct or can we do pre-commit triggers with it? If > not would we have to use the "bare-bones" trigger? > > cheers, > Jakob. > CPF generally uses post-commit triggers, true. There are some pre-commit triggers, but they try to do the smallest amount of work possible, e.g. setting the processing status so the post-commit triggers can go to work. If, truly, all you want to do with triggers or CPF is just this one little thing, then using a bare-bones trigger is fine. Pre-commit triggers shouldn't do too much work, so be careful. The advantage/disadvantage is that validation errors would error out the whole transaction so the document would not be inserted, but also no other documents inserted in that transaction would go in the database either. So, be sure that is what you really want. In a post-commit CPF world you can selectively shoot just the ones that failed validation. However, if you find that you want to do "just one more thing" or use any of the CPF applications (including things like flexrep), use CPF. It is really, really hard to get multiple triggers to coordinate and play nice together, and you will not enjoy the experience. Oh no. You surely won't. MarkLogic does ship with a validation pipeline for CPF that sets invalid documents into a validation-error state that you could then hook your own pipeline to to kill the bad ones or whatever. //Mary _______________________________________________ General mailing list General@developer.marklogic.com http://developer.marklogic.com/mailman/listinfo/general
