Well, right, that's my point (transactions not being a persistence issue) -- you can build your business logic API to do the various sets of atomic operations (thus, my example of using a persistence mechanism that is unaware of transactions inside the business logic layer) but wrap them in transactions as appropriate.
Your new solution using the CFQUERY tag to begin and end your transactions seems like another work around, but I don't quite understand the value of that particular encapsulation (which is not to say it's a bad idea). I was merely trying to flush out ways to get the transactions enforced without resorting to ugliness in the API itself. I am also tempted to argue that transactions themselves should be encapsulated in the business logic API rather than ever relying on the end-developer to do the "right thing" with transactions, which would obviate the need to have public methods for beginning/ending/rolling back transactions. Yes, transactions needs to happen at different levels of granularity, but that's what development of the API is for in the first place at some level. It seems cleaner to enforce it inside the business logic layer -- that was, I guess, my original question about missing the boat ;) - Nathan > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Barney Boisvert > Sent: Thursday, December 04, 2003 2:31 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] cftransaction with CFC's > > > 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? > > > > ---------------------------------------------------------- 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]
