oops. by "so totally sure" i meant "not totally sure", of course ;-)
Jonathan Locke wrote: > > > the original idea was that you might want to version pages some other way. > for example if you want to capture every last change to the page for sure > at the cost of some extra memory, you could do a deep clone. i have no > problem > with getting rid of the interface and making the entire implementation > private. > when i wrote this, it seemed there might be other ways to do this. in > hindsight, i > think this is a job for the framework alone and not something we want > people > mucking with. given that, i don't think it matters how ugly the > implementation > is so long as it writes out just the diffs (retrievals of disk stored > pages accessed > with the back button will be quite rare so a greater cost of > reconstructing is easily > offset by a cheaper cost of writing the diffs). conceptually it now seems > like the > design has shifted indeed and that the logical place to put all the > versioning is > down inside the pagemap implementation such that it shares that > information > with whatever session store is in use. the session store would use the > change > information however it wants. in that manner someone could write their > own > versioning code if they really wanted to. but it would be a private > implementation > detail of the session store that nobody should ever see. so page would > forward > info to pagemap and pagemap to session store impl. so totally sure if > that works > out completely, but it's a thought. > > btw, SecondLevelCacheSessionStore seems a little fuzzy to me as a name. > it presumes someone knows what a "second level cache" is. what about > something a little more direct like maybe FileBackedSessionStore? not > sure > i love that either, but it's maybe a little more obvious. > > > igor.vaynberg wrote: >> >> i dont even see the point of having an IPageVersionManager. it is tied to >> Change which has an undo() method, so what other kind of manager can you >> write except the undo one? >> >> -igor >> >> >> On 1/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: >>> >>> Hi, >>> >>> Currently, pages and versions of pages are stored separately. Pages >>> are stored in IPageMaps, and each page has a IPageVersionManager. By >>> default (and I wonder how many users actually ever did override this) >>> the IPageVersionManager is UndoPageVersionManager, which keeps a list >>> of changes in the instance. As the instance is kept as a reference of >>> the page, the size of a page in a session is the sum of the size of >>> the actual page at that time + the size of the list of all the >>> changes. This is regardless of how the PageMap/ session store works >>> unfortunately, and by default, you can have Integer.MAX versions. That >>> potentially fills up memory pretty badly if you do a lot of component >>> replacement. And Integer.MAX isn't the best guarantee to keep memory >>> down either. Furthermore, it works pretty lousy with the new session >>> store. That store saves every page/ version combination to disk, but >>> including the whole version manager (all versions), which is >>> inefficient. With this way of saving, you really don't need more than >>> one. Anyway, to make a long story short here is what I think we should >>> do: >>> >>> - Align pagemaps and version management so that pages and versions are >>> stored in, and retrieved from the same entity. >>> - Change the SecondLevelCacheSessionStore so that it either saves >>> pages without the version manager but rather exactly as they are at >>> that moment or save the first version as a full page, and subsequent >>> versions as changes. This would be my choice as it is more efficient >>> in especially storing it, and storing is the part having a greater >>> impact than retrieving. >>> - Page should only use a temporary instance of IPageVersionManager and >>> the newVersionManager method could be private imo as I don't see much >>> use now users being able to provide their own (in fact, we could get >>> rid of the IPageVersionManager interface). When endVersion is called, >>> the changes would be flushed and saved to the pagemap and the version >>> manager instance should be nulled. >>> >>> WDYT? >>> >>> Eelco >>> >> >> > > -- View this message in context: http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8232968 Sent from the Wicket - Dev mailing list archive at Nabble.com.
