PersonManager.beginTransaction() would look like this:
method beginTransaction() {
getPersonPersistor.beginTransaction();
}
It's nothing more than a passthrough method for the sake of the Listener,
because the Listener doesn't have a reference to the persistance object. In
PersonPersistor, the method would contain a single CFTRANSACTION tag if
you're using a transactional database, nothing if you're using a
non-transactional database, some CFLOCKS or something if you're using XML
files, or whatever. I'd set this up in an AbstractPersistor class that all
my Persistors extend. Chances are very good that all the persostors will
have the same transaction mechanism, but i can still override it in specific
persistors if I need to.
If a Person object has an internal Address object, then the
PersonPersister's persist() method might look like this:
method persist(person) {
CFQUERY
UPDATE person SET ...
getPersonManager().getAddressManager().persistAddress(person.getAddress());
}
Or, it could well be that your address data is stored in the same table as
your person data:
method persist(person) {
CFQUERY
UPDATE person SET
...
address = '#person.getAddress().getStreet()#',
state = '#person.getAddress().getState()#'
...
}
Or, perhaps the Address object is used for lots of things (Persons, Offices,
Stores, etc.), so you can't have a generic persistAddress() in an
AddressManager, because it's ambigious as to where to store it, becasuse
different type (Person, Office, ...) have different storage mechanisms. In
that case, you'll need to handle the Address persistance as part of the
Person persistance, so you'll have multiple SQL statements in your persist()
method:
method persist(person) {
CFQUERY
UPDATE person SET ...
CFQUERY name "get"
SELECT addressID FROM personAddress WHERE personID = #person.getId()#
LOOP collection #person.getAddressList()# item i
IF listFind(valueList(get.addressID), i.getId())
CFQUERY
UPDATE personAddress SET ...
ELSE
CFQUERY
INSERT INTO personAddress ...
/IF
/LOOP
<!-- now check for addresses to delete -->
}
Of the three, I suspect that the third will be the most common, and i'd say
it's the best in general as well, because it allows you to transparently
reuse the Address class for various different types of addresses, and that's
always a good thing.
barneyb
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Jon Gunnip
> Sent: Thursday, October 16, 2003 1:31 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] Strugling With Persistence
>
>
>
> I'm curious:
>
> What would the internals of PersonManager.beginTransaction(),
> PersonManager.commitTransaction(), and
> PersonManager.rollbackTransaction() look like?
>
> I am especially interested in the case where the PersonObject has
> 1 or more nested objects. For example, what if the PersonObj had
> an AddressObject and you wanted to submit the PersonObj and
> AddressObj changes in one "transaction"?
>
> I assume getPersonPersister().persistPerson(person) or the
> PersonManager would then call some sort of AddressManager who
> would call a getAddressPersister.persistAddress(address).
>
> But would this work with a transaction that would support a full
> rollback of address and person changes in the case of a problem?
>
> Would you use a Memento Object for the Person and for the Address
> prior to storing the new object state and then the
> rollbackTransaction, if called, would reinstate the Memento Objects?
>
> Thanks,
> Jon
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word '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]
