That's what I tend to do as well: write DB Specific code encapsulated into components (or, before, custom tags) with defined interfaces.
I think that I'm going to change my method for this now that I know more about CFCS. I had been using single "Broker" CFCs which called out to DB-specific includes (based on the current DB Type), but considering this transaction business I'll probably try to create DB Specific brokers and figure out some way to call them dynamically. Jim Davis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Barney Boisvert > Sent: Thursday, December 04, 2003 5:16 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] cftransaction with CFC's > > Yeah, I'm quite put out by the whole thing. It seems very strange to me > that CF took a step back from every DMBS I've ever used, by making > transaction control statements depend on eachother, rather than being > standalone commands. I suppose the tag-based nature of the language > demanded it, but then to go against that nature and allow standalone tags, > but only within an existing open/close tag pair seems really f***ed up. > One > or the other, ya know? > > Actually, as someone mentioned, you can skip the CFTRANSACTION tag, and > run > a CFQUERY with <WHATEVER> TRANSACTION as the SQL and it'll work, but at > the > expense of potentially being tied to a specific SQL dialect. However, > I've > yet to write a component containing SQL with the intention of it being > cross-DB. I much prefer to write a DB-specific component for each target > database, all extending a generic component (it'd be an interface/adapter > pair in Java). If that type of architecture is used, then the native SQL > commands option is just as viable as the CFTRANSACTION mechanism. > > Cheers, > barneyb > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Jim Davis > > Sent: Thursday, December 04, 2003 1:55 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] cftransaction with CFC's > > > > Well - I would have rather been wrong than you. ;^) > > > > Right now I'm considering setting up some sort of "DoSQL" component - > > instantiate it at the beginning of a process, append the SQL > > to it as the > > process continues (perhaps creating mementos as it goes) and > > then committing > > all the SQL at once in one big transaction. > > > > This way even a highly recursive object model (as mine tend > > to be) could > > (pretty cleanly) take advantage of transactions... I'm not > > sure if you could > > still take advantage of CFQUERYPARAM/CFSTOREDPROC however... > > I'll have to > > give it some thought. > > > > In any case it seems like CFTRANSACTION could really use an overhaul. > > > > Jim Davis > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > > > Of Barney Boisvert > > > Sent: Thursday, December 04, 2003 4:40 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [CFCDev] cftransaction with CFC's > > > > > > Jim, sure enough, I just tested this on 6.1, and it does > > NOT behave as > > > intended. I'm quite confident it worked that way on 4.5, but hadn't > > > tested > > > recently. The test script I ran is below. You'll need a > > datasource named > > > 'test' with a table named 'test' containing a varchar > > column named 'name' > > > to > > > execute it. > > > > > > So, this mechanism will NOT WORK. My sincerest apologies to all who > > > assumed > > > I was not speaking from my rear. Entirely my fault for not double > > > checking. > > > Back to the drawing board. > > > > > > Apologies, > > > barneyb > > > > > > > > > <cfset request.dsn = "test" /> > > > > > > <!--- get the initial status of the table ---> > > > <cfquery datasource="#request.dsn#" name="get"> > > > SELECT * > > > FROM test > > > </cfquery> > > > <cfoutput><p>Current Table Status:</p></cfoutput> > > > <cfdump var="#get#" /> > > > > > > > > > <!--- begin a transaction, running a 'good' query and a > > 'bad' query ---> > > > <cftry> > > > <cftransaction action="begin"> > > > > > > <cfquery datasource="#request.dsn#" name=""> > > > INSERT INTO test > > > (name) > > > VALUES > > > ('emery') > > > </cfquery> > > > > > > <cfquery datasource="#request.dsn#" name=""> > > > INSERT INTO test > > > (name) > > > VALUES > > > </cfquery> > > > > > > <cftransaction action="commit"> > > > <cfcatch type="any"> > > > <cfoutput><p>error occurred: > > > #cfcatch.message#</p></cfoutput> > > > </cfcatch> > > > </cftry> > > > > > > <cfquery datasource="#request.dsn#" name="get"> > > > SELECT * > > > FROM test > > > </cfquery> > > > <cfoutput><p>Current Table Status:</p></cfoutput> > > > <cfdump var="#get#" /> > > > > > > > > > <!--- begin a transaction, running a 'good' query and a 'bad' query, > > > manually doing the rollback ---> > > > <cftry> > > > <cftry> > > > <cftransaction action="begin"> > > > > > > <cfquery datasource="#request.dsn#" name=""> > > > INSERT INTO test > > > (name) > > > VALUES > > > ('emery') > > > </cfquery> > > > > > > <cfquery datasource="#request.dsn#" name=""> > > > INSERT INTO test > > > (name) > > > VALUES > > > </cfquery> > > > > > > <cftransaction action="commit"> > > > <cfcatch type="database"> > > > <cftransaction action="rollback"> > > > </cfcatch> > > > </cftry> > > > <cfcatch type="any"> > > > <cfoutput><p>error occurred: > > > #cfcatch.message#</p></cfoutput> > > > </cfcatch> > > > </cftry> > > > > > > <cfquery datasource="#request.dsn#" name="get"> > > > SELECT * > > > FROM test > > > </cfquery> > > > <cfoutput><p>Current Table Status:</p></cfoutput> > > > <cfdump var="#get#" /> > > > > > > ---------------------------------------------------------- > > > You are subscribed to cfcdev. To unsubscribe, send an email > > > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > > in the message of the email. > > > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > > by Mindtool, Corporation (www.mindtool.com). > > > > > > An archive of the CFCDev list is available at www.mail- > > > archive.com/[EMAIL PROTECTED] > > > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email > > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > in the message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail- > archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
