From: JT S. <jt...@pl...> - 2004-07-11 16:20:49
|
I'm not saying that your point is unreasonable, but this side effect is part of using replicated databases. I cannot think of a way to implement this in a reasonable manner that will also solve the problem you bring up. I'm not sure it was you, but someone mentioned that if the user ever edits something during their session, then for the rest of their session they should never get anything from a slave again. At that point you might as well not even use slaves, cuz they'll hardly ever be used. I also think that there's not much of a reason to solve a problem that does not yet exist. Before we spend a ton of time engineering a solution to a problem that doesn't exist, let's see if the people that actually use this functionality find this or other things to be a problem. Could we do that? On Sun, 11 Jul 2004 08:52:01 -0700 David Schwartz <dp...@di...> wrote: >The discussion thus far has reached the point where y'all have figured out a way to >divert >requests for multiple databases to just the master, but on a session-based granularity. >I've brought up a legitimate scenario when someone would be working in such an >environment >and make some changes, then close the session and want to view their changes "live" >before >proceeding with more changes. I don't think this scenario is unreasonable or even very >rare. > >The implication in your reply is that the WG content admin would have some idea of how >long >it would take to propagate the changes based on the internal server architecture. I >think >you are making an assumption here where the guy who's the "Admin" of the WG content is >also >the "admin" of the servers. For a single-server scenario, that's probably valid. But >when >you start to venture off into sites that are sophisticated enough to require replicated >databases, it's increasingly likely that the site content admin is not the same person >who >maintains the operation of the servers themselves. > >It's probably no skin off my back because I can't image running replicated databases, >not >for a while at least. But, in the spirit of contributing to the discussion, I'm just >suggesting a reasonable usage scenario that you might want to take into consideration >in >your present design. > >-David > >JT Smith wrote: > >> If you are running multiple databases, which you probably won't be, yes it could take >>a >> few seconds or even minutes to see your changes. It really depends upon how busy your >> servers are as to how quickly they are resynced. >> >> 98% of WebGUI users will never use multiple databases, and therefore won't even know >> that this feature exists, and won't be affected by it. >> >> On Sat, 10 Jul 2004 00:48:09 -0700 >> David Schwartz <dp...@di...> wrote: >> >When I modify a WG site (in Admin mode), I tend to put some stuff on a page, >> >then have a look at it from the "outside" (after logging out) to be sure I got >> >all of my security settings correct. What happens in this situation? If it >> >takes "a while" (are we talking seconds, minutes, or what?) for the slaves to >> >get updated, my interpretation of this discussions implies that it's fairly >> >likely that none of the changes made in Admin mode will actually be visible for >> >"a while". Or am I missing something? >> > >> >-David >> > >> >Christian Zoellin wrote: >> > > > > >------------------------------------------------------- >This SF.Net email sponsored by Black Hat Briefings & Training. >Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >digital self defense, top technical experts, no vendor pitches, >unmatched networking opportunities. Visit www.blackhat.com >_______________________________________________ >Pbwebgui-development mailing list >Pbw...@li... >https://lists.sourceforge.net/lists/listinfo/pbwebgui-development JT ~ Plain Black Create like a god, command like a king, work like a slave. |