I know table locks work in that they prevent inserts while the lock is active. I meant that it wouldn't work in the context of this discussion to guarantee uniqueness. I'm glad we agree that the unique key is the only robust way to guarantee uniqueness. It's not such a "horrible option" after all. ;)
-Phil On Wed, 3 Nov 2004 14:48:59 -0800, Barney Boisvert <[EMAIL PROTECTED]> wrote: > Table locks will definitely work, because they'll prevent anyone from > inserting a new record (with a new username) between the time you > check the username and the time you insert it. It's exactly the same > as a CFLOCK, except it happens to a DB table, not a block of > application code. However, I agree that the unique key is the final > and absolute check for uniqueness, and really, if you have that in > place, then the rest of it is pretty much irrelevant. > > userHome also acts as a factory for user objects, and for pulling > collections of them as well. I might want a recordset of user info > for rendering a table of users. But I might want a collection of user > objects for expiring passwords on them (or whatever). If you're > familiar with EJBs, it'd be like the Home interface for an entity > bean. Obviously they don't match up exactly because of enormous > environmental differences, but at a high level they are roughly > equivalent. > > cheers, > barneyb > > ---------------------------------------------------------- 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]
