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#a8232952 Sent from the Wicket - Dev mailing list archive at Nabble.com.
