Return-Path: Delivered-To: apmail-xml-cocoon-users-archive@xml.apache.org Received: (qmail 55282 invoked by uid 500); 23 Feb 2002 14:24:02 -0000 Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-users@xml.apache.org Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 55271 invoked from network); 23 Feb 2002 14:24:01 -0000 Date: Sat, 23 Feb 2002 15:23:11 +0100 From: Christian Haul To: cocoon-users@xml.apache.org Subject: Re: howto make use of default database add, delete, update action for mutilple table at a time Message-ID: <20020223152311.C29479@bremen.dvs1.informatik.tu-darmstadt.de> Reply-To: haul@dvs1.informatik.tu-darmstadt.de References: <20020222095410.P3588@bremen.dvs1.informatik.tu-darmstadt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Organization: Databases and Distributed Systems Group, Darmstadt University of Technology X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 22.Feb.2002 -- 11:13 PM, Pascal Davoust wrote: > I read in a post a few days ago (or was it in the archive?) that there were > some serious limitations with these actions, and that some work is currently > done to overcome those (something is already available in the scratchpad to > have a look, I believe). A word of warning: The way the actions are used (declaration of modes and all classnames will change very shortly. Actually, that work is already done but since I haven't found the (spare) time to check they still work as expected it's not in the CVS, yet. Hope to find some time over this weekend though.) What is "better" with the new ones: *) all actions work on arbitrary number of tables *) all actions may work on arbitrary number of tuples *) configuration is done in one file, table-sets select the tables to work on *) autoincrement columns work better (currently mysql, hsqldb, informix, but it's very easy to support any other as well) *) values can be obtained from arbitrary sources, source can be specified per table-set and column *) results can be written to arbitrary destinations *) in- / output helper modules can be used with other components like matchers, selectors, actions (currently, only one example exists) *) currently available modules: request attributes (in/out), request parameters (in), request header (in) session attributes (in/out) more to come... What is "worse" with the new ones: *) descriptor file syntax has changed *) uses additional components -> more complex -> slower (?) *) changes are on the way > Does anybody know if this *serious* limitation could be part of the new, > future, top-notch database actions? What limitation are you refering to? Updating multiple tables / rows? Yes, that should be possible. Chris. -- C h r i s t i a n H a u l haul@informatik.tu-darmstadt.de fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. To unsubscribe, e-mail: For additional commands, e-mail: