I agree that for the most part the implementing developer of the CFC
shouldn't need to worry about transactions - for the most part I wonder
if they even need to know that there's a database. ;^)
I'm new to OO and struggled with this as well. I ended up with (perhaps
a poor) model that seems to
I agree completely, but that CFC (or CFCs) is business-layer, not
persistance, because it encapsulates business logic. I was only discussing
the interaction between business layer and persistance layer, not
necessarily between your actual business objects, and the persistance layer
(which would li
Well, some DBs will let you have nested transactions, AFAIK, so that might
be an option (in other words, just put the transaction logic in both
saveUser and saveUsers.
Also, if saveUsers (or, saveUserBatch, in your lexicon) is just going to
call the same few methods of your persister, I would say
Thanks Nathan.. I don't think you're missing the boat at all. This is
exactly like the problem I'm attempting to solve.
To recap..
These functions do not contain any transaction logic at all...
insertUser(id,fname,lname,email);
associateUserWithDepartment(userID,deptID);
associateUserAsDirectRe
Can I ask: why not just build a CFC layer that exposes a simple API that
does the transaction internally, then have that layer make use of your
underlying persistence mechanism? That is, why make an end-developer have
to even think about transactions if they are a known quantity in advance?
Instea
I'm not sure I have an answer to that one, as you're kind of mixing
different styles. I think I'd still say that a transaction can only be
controlled from the upper level, outside the function, so you'd need to add
CFTRANSACTION tags around the first CFINVOKE, just like the second set.
Here's ano
Hey Barney,
What about if you're not using OO modelling? This is for a procedural
system. A pseudo implementation might be...
- j.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Barney Boisvert
Sent: Tuesday, November
Very abstract, rather academic:
http://www.ambysoft.com/persistenceLayer.html If followed to a "T", it would
produce an unusable persistence model in ColdFusion.
NAT
> There have been a couple discussions here about persistence
> components, but I'm not quite sure I ever understood them or
> how
Data integrity is definitely a business logic concern. The persistance
layer only cares about type validity (int, decimal, string, etc), it should
have no knowledge of what a given piece of data actually means, or whether
it needs to be kept in sync with some other piece of data (which is an even
In my way of thinking, transactions are a pure business logic "thing", they
have nothing to do with persistance (though that's where they're actually
implemented).
Although I'm not sure about this (is data integrity really
part of business logic?), I like your thinking and the model
code you sho
In my way of thinking, transactions are a pure business logic "thing", they
have nothing to do with persistance (though that's where they're actually
implemented). If you accept that as valid, then there is never a need to
deal with transactions anywhere except in your business logic components, s
I could use an opinion from you gurus out there..
Given a situation where you want to use a cftransaction block in a low level
module, there is a typical problem that comes up. In some cases, you may
want to call this function on it's own, and in others you may want to have
an "outer" transaction
See attached.
/*
* Created on Sep 27, 2003
*
* @author mliotta
*/
package com.montarasoftware.cfx;
import org.apache.bsf.BSFEngine;
import org.apache.bsf.BSFManager;
import com.allaire.cfx.CustomTag;
import com.allaire.cfx.Request;
import com.allaire.cfx.Response;
/**
* @author mliotta
*
Note that we don't support Mach II yet, so don't even try it. :-)
So you don't want me to file a bug for that then? :)
I used Mach II as a test for BlueDragon's CFC implementation since I
figured it would provide interesting results. Interestingly, the
process has had me find both Mach II and Bl
On Nov 18, 2003, at 6:51 AM, Vince Bonfanti wrote:
There's a "Known-Issues.txt" document in the "docs" directory of the
BD 6.1
installation that lists known issues with the current beta.
OK, thanx.
One area I know we're going to be different is we
don't tri-state the OUTPUT attribute; our "YES" c
Hi Sean,
There's a "Known-Issues.txt" document in the "docs" directory of the BD 6.1
installation that lists known issues with the current beta. The intention is
that BD 6.1 will be fully compatible with CFMX 6.1 before the final release;
any exceptions and enhancements will be documented in the B
16 matches
Mail list logo
