>> I've worked on some very large-scale, complex web applications, and I've never had >> a case where this sort of pseudo-record-locking approach was needed.
Dave, this is mearly a request for clarification (not a flame or anything), since this whole issue was brought up on a fellow team members' blog a couple of weeks ago (with lackluster replies) would it be safe to say that the methods mentioned (re-read before write, timestamps, hashing, etc) always worked well for you so nothing else was seriously considered? you were able to build this into the system from day one, the bloody thing worked perfectly and that was the end of the story? Mate, I'm with you on this. timestamps have worked well for me in the past (I've never used the hashed record method for this but I can't see why that wouldn't work either). In my pre CFMX days (ASP/ASP.NET) no one bothered with anything else. BUT...that's not saying this "mad idea" won't work. The user base is asking for this (locking + notification) as a feature request, the boss (a client/server programmer for 20 years but who doesn't yet fully appreciate *all* of the intracacies web apps have) is saying "Why Not". If it were up to me, I'd be happy to use timestamps, take the hit in schedual, rebuild the app, saying "tough" to this unwieldy request and get on with it. >> The level of complexity this will add will be significant, in my opinion. Dave, I don't disagree. Knowing what is wanted, we were told to explore options. Meanwhile we're still churning out code, knowing the (many) hundreds of update and delete methods that will need *something* to handle the issue. That's why the leftfield inquiry into AOP, or rebuilding cfquery with additional "hooks" (same idea really - add another aspect to the apps' execution). If someone can save us some angst and has actually tried to go down this road (and found nothing but a world of pain, as opposed to the formentioned solutions that we all know *do* work), please feel free, etc. Until then (in his eyes) the boss has got reason to piss us around with (potentially) unworkable solutions. but I'm digressing too far into software development and project management issues (apologies for the background info diatribe) To bring it back to technical stuff: Ben, your concerns of still not addressing all of the data collision: Yeah, you're right. I raised this on Tuesday - it's an area that is not fully thought out yet (well, none of it is really). Storing the hash of old data in the "lock table" is an interesting thought, although it might differ somewhat to what you propose. My gut feeling is that the presenter (coming back to the archetecture) will end up playing a significant role in this. I hadn't thought of using triggers to automate some of this (D'oh!). thanx Dave and Ben for your (most welcome) thoughts I'll bring all of this up with the team tomorrow - kick it around some more. cheers barry.b -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ---------------------------------------------------------- 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]
