Thanks Mary. We really'd like to use CPF and not reinvent it using the underlying triggers.
I want to validate and transform an input document (or indeed a batch), and store the transformed document. Only if all three actions (validation, transformation and storage) go well, do I want to also store the initial input document. This is why I was thinking pre-commit trigger. Now, you're suggesting to do this with post-commit: I validate (if that goes wrong the document is moved to a validation error state), and then I transform (this could also go wrong) and then I store (which, I guess, would be third possibility of things going awry). So, if any of these actions result in a document being moved to an error state, I'd need actions to deal with the situation, such as deleting the previously stored input document (this being a post-commit trigger) and returning some information on that the action has been rolled back and why. If this sounds reasonable then I think we can indeed use CPF. cheers, Jakob. On Thu, Jul 11, 2013 at 11:53 PM, Mary Holstege <[email protected] > wrote: > On Thu, 11 Jul 2013 14:25:31 -0700, Jakob Fix <[email protected]> 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 > [email protected] > http://developer.marklogic.com/mailman/listinfo/general >
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
