Thanks - I wasn't really concerned about figuring out a method tho'. ;^) Right now I've been using a "DPDataSource.cfc" that contains basic information about a datasource (it should probably be a simple struct, but I like the CFC notation) including (among other things) the database type.
I like your idea a little better. For one thing although my current method works with a DataSource type of "XML", for example, terminology is a little misleading... at the same time I hate (for some reason) typing the word "Persist". I think that your "Persisters" and my "Brokers" are very similar things... when a component wants to save/fetch/whatever from the datastore it creates a broker which uses the value in the DPDataSource to determine how to deal with the datastore in use. Of course I'm winging this... I've got no OO in background at all. But I'm happy that my instincts seem to have been close even if my terminology was way off. ;^) I had begun using includes just because I thought it would be nice to separate out long, "messy" DB/XML/Whatever code from the broker code (which handled all interaction with the object model)... I still think it is, actually. My one problem is that it also then became harder to properly "var" scope my variables (since many of them were used in includes only. I guess it's a trade off either way... Jim Davis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Barney Boisvert > Sent: Thursday, December 04, 2003 6:37 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] cftransaction with CFC's > > Set an application variable that's the persistance mechanism to use (or an > app property, if you're using Mach-II). Then write a Factory component > that > takes a persistance mechanism name as a parameter to init(), and has > methods > for returning different persistance objects: > > Component PersisterFactory { > method init(cfcroot, mechanism) { > if (NOT listFind("MySQL,MSSQL,FlatFile,XML,etc", mechanism)) > throw IllegalPersistanceMechanismException; > variables.my.cfcroot = cfcroot & ".persistance." & mechanism; > } > > method getPersonDAO(..args..) { > var obj = > createObject("component","#variables.my.cfcroot#.PersonDAO"); > obj.init(..args..); > return obj; > } > > <!--- more methods for more persistance object types ---> > } > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Jim Davis > > Sent: Thursday, December 04, 2003 3:23 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] cftransaction with CFC's > > > > 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] > > > > ---------------------------------------------------------- > 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]
