require a lot of "outside" knowledge on the part of the CFCs. In other
words they would have to know to loop and call and whatnot these
entities specially in certain circumstances. I'm trying (but it looks
like I'll fail) to make things as DB agnostic as possible.
For example I've got a "Venue" component which can be any sort of venue
(a building, a park, a room, etc) where a performance or exhibition can
take place. This Venue component can have a "Parent" (another Venue
Component) and zero or more "Children" (Venue Components contained in a
special "VenueCollection" Component).
The "user" only deals (for the sake of discussion) with the Venue
comoponent - it has methods like new(), save(), delete(), etc.
Internally, however the Venue component provides these persistence
services via a VenueBroker component - it's this component that does all
the work on the DB. It has methods like save(), delete(), etc that take
Venue components as arguments.
This is working out nicely: the interface only worries about "talking"
to the domain components and they don't worry at all about the
persistence implementation which is handled by the broker.
However when I call "myVenue.delete()" (which internally calls
"myVenueBroker.delete(this)") and want to loop through the collection of
children and delete them as well I end up with the nesting errors since
(I think logically) I'm just calling the delete() methods of the
children. Even if I create "entity" components for the broker to call
I'm still stuck with this. The way would be to separate the broker and
the base component completely - but then the interface code needs to be
much more knowledgeable about the way things are working beneath the
covers. or so it seems to me.
In general I'd rather keep my complexity at the broker level and keep
the domain components more "pure" - I'd like the interface to just say
"myVenue.delete()" and be done with it rather than have to understand
the broker (or, in your case, managers).
Perhaps I've modeled this all wrong.
Jim Davis
-----Original Message-----
From: Christian Cantrell [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 11:37 AM
To: CF-Talk
Subject: Re: Nesting CFTRANSACTION?
On Friday, October 3, 2003, at 01:14 AM, Jim Davis wrote:
> However when I do this (as I am) from with the parents delete() method
> (making the call sorta recursive-like) I get the error we all know and
> love: "Cannot nest CFTRANSACTIONS"
The approach I sometimes take is to have a set of components called
entities which only worry about a single database table (the
relationship between an entity and a database table is usually 1 to 1).
For instance, I might have a User entity, and an Orders entity. Each
contains functions (and SQL) for inserting, updating and deleting.
Calling the deleteUser function of the User entity would often fail
because of referential integrity violations if that particular user had
any orders. That's where the higher-level components come in: the
managers.
I create a second package of components called "managers" which handle
transactions and "glue" entities together. The User manager component
might have a delete function which does the following:
1. Starts a transaction.
2. Deletes all of the users orders.
3. Deletes the user.
4. Commits the transaction.
These types of "cascading deletes" can get as complex as you need them
to. The key is to keep all your SQL in your entities, and all your
transactions in your managers.
Christian
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
