Transactions might need to be applied at different levels of granularity. Say I need to add an employee, as your method does. Wouldn't you want a transaction block around all three statements? If the insertEmployee rolls back, you don't want to continue, right? And if the associate..() method fails, you'd want to uninsert the employee and figure out what went wrong.
Transactions are not a persistance concept, they are a business-logic concept. With/without transactions, the database will always have a consistent picture at the data level. However, it might not be consistent at the business logic level. Same thing goes for foreign keys. They are a business-logic concern, nothing to do with persistance at all. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Dintenfass > Sent: Thursday, December 04, 2003 2:21 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] cftransaction with CFC's > > This may be a very naive perspective, but in all of this > discussion I am > curious about two things: > > 1) My understanding is that in CF 6.1 that CFTRANSACTION tags will be > honored even in CFC methods called inside the Transaction > block. If you are > going to set up a system whereby you have to manually "start" > and "end" a > transaction anyway, why not just do it the old-fashioned way? > > 2) More interestingly, why not build out your component model > to accommodate > an API that honors transactions internally. That is, build out your > persistence CFCs to do the granular data CRUD, then build a > layer above that > used by the end-developer that ties things together into a > more meaningful > API which, internally, implements the transaction? For > example, a rough > example might look something like: > > <cffunction name="saveEmployee"....> > <cfargument name="employeeObj"...> > <cftransaction> > <cfscript> > variables.persister.insertEmployee(...); > variables.persister.associateEmployeeWithDepartment(...); > variables.persister.createDirectReport(...); > </cfscript> > </cftransaction> > </cffunction> > > That seems like it would yield a much cleaner API for a > developer to use > anyway, and would prevent the nastiness you describe in your "DoSQL" > component. You can then build out the API of the low-level > persistence to > be ignorant of transactions (as it probably should be) and > then build your > "business logic" layer to know about those rules (as it > probably should). > > Am I missing the boat here? > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > 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]
