Hey Paul, i already have a buggy and untested prototype of the CouchDB backend that is as small as 300 loc. I think an additional abstraction of the document layer may only complicate the implementation or just lead to all API methods being delegated to yet another backend. Its probably easier to just have an additional ezcWorkflowMongoTiein that is equally thin.
Regarding the non-Update only Insert, ezcWorkflowDatabaseTiein operates exactly the same. Yes i have very long running workflows that may change often, so this is an important requirements (for me). But i think this behaviour is important for short workflows of just some minutes execution also. greetings, Benjamin On Tue, 27 Jul 2010 00:06:00 +0200, Paul Borgermans <paul.borgerm...@gmail.com> wrote: > Hi > > On Mon, Jul 26, 2010 at 9:14 PM, Benjamin Eberlei <kont...@beberlei.de> > wrote: >> Hello everyone, >> >> i want to propose the development of a CouchDB Storage Tiein for the >> Workflow Engine. It would be a considerable improvement over the >> Database backend, for various reasons: > > Maybe abstract it to have easy tie ins for other document oriented > databases? > >> >> 1. Several variables are saved as PHP serialize() output in LONGTEXT >> fields in both the Workflow and Execution parts of the Engine. This is >> rather problematic (and ugly). Workflow just has many "unrelational" >> parts such as node configuration, execution state/variables and thread >> information. CouchDB could just nest them as sub-objects in JSON. > > +1, and also return JSON constructs for potential use in view layers > >> >> 2. Database backend uses serialized php data for Execution::$variables >> and Execution::$waitingFor, both variables that are interesting for >> querying the set of existing workflows. Views can be easily written >> using any of the two as keys to select for. > > Yes! > >> >> 3. Both a workflow and an execution could be saved in a single document >> each. >> >> Why a workflow? Workflows are never updated, only saved with a new ID. >> Otherwise you could seriously destroy currently existing executions of a >> changed workflow. Therefore no problems exists with read/write >> contention or version conflicts. >> > > Fair enough, is your use-case involving "long-lived" workflows? > > About the execution, I see MongoDB as an attractive alternative too, > because it allows updates in place for a single key/field, further > minimizing the overhead for tracking this execution part > >> Why an execution? It has to be resurrected from persistence completely >> in any case, the nested data is never of any interest in an incomplete >> context. You always need the whole data. > > Indeed, at least for as far I dived into and understand the workflow > component at this stage > >> >> What do you think of the idea? Is there interest in this development? > > I think so, but I am biased towards doc-oriented backends anyway > > my 0.02€ > > Paul
