|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
[Bug 597] New: Aggressive cachemode leads to problems with grouped collectionshttp://helma.org/bugs/show_bug.cgi?id=597
Summary: Aggressive cachemode leads to problems with grouped collections Product: Helma Version: 1.6.1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: Database Layer AssignedTo: helma-dev@... ReportedBy: robert@... Defining "cachemode=aggressive" for a grouped collection leads to wrong behaviour: when adding a HopObject to a grouped collection where the appropriate groupnode doesn't already exist the HopObject won't be accessible using collection.get(groupname).get(0) afterwards. The HopObject will only be part of the collection if the application is flushed, restarted or another HopObject is added to the same groupnode of the grouped collection. To reproduce this behaviour put the following action into a global or root .js file in Gobi (note that you need to modify the Page id in the first line of the action): Root.prototype._debug_action = function() { // change the page id to an existing one (eg. a skin) var pageId = 1173; var page = Page.getById(pageId); var type = "system:justatest"; var direction = "out"; if (req.data.action) { if (req.data.action == "add") { this.addLink(type, direction, page); } else if (req.data.action == "remove") { this.removeLink(type, direction, page); } else if (req.data.action == "flush") { app.clearCache(); } res.redirect(this.href(req.action)); } else { var groupObj = this.links_out.get(type); res.debug("groupobject: " + groupObj); if (groupObj != null) { res.debug("link: " + groupObj.get(String(pageId))); } } return; }; Then, with a freshly started gobi application, do the following: 1) request the _debug action: the groupobject should be null 2) request the debug action with "?action=add" as argument: the groupobject will still be null, which is wrong 3) request the debug aciton with "?action=flush" and both groupobject and the added link should be visible 4) from now on adding/removing will work, because the groupnode "system:justatest" already exists. however, if the groupnode is empty and the application is restarted or flushed, the wrong behaviour appears again. -- Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. _______________________________________________ Helma-dev mailing list Helma-dev@... http://helma.org/mailman/listinfo/helma-dev |
|
|
[Bug 597] Aggressive cachemode leads to problems with grouped collectionshttp://helma.org/bugs/show_bug.cgi?id=597
------- Comment #1 from hannes@... 2008-04-04 17:29 ------- Created an attachment (id=89) --> (http://helma.org/bugs/attachment.cgi?id=89&action=view) Collective patch for bugs #597, #614, and #615 Fixes this bug plus #614 and #615. Not sure if this is safe for helma 1.6.2, though. -- Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. _______________________________________________ Helma-dev mailing list Helma-dev@... http://helma.org/mailman/listinfo/helma-dev |
|
|
[Bug 597] Aggressive cachemode leads to problems with grouped collectionshttp://helma.org/bugs/show_bug.cgi?id=597
hannes@... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Target Milestone|--- |1.7.0 ------- Comment #2 from hannes@... 2008-04-07 17:24 ------- Committed patch to trunk. -- Configure bugmail: http://helma.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. _______________________________________________ Helma-dev mailing list Helma-dev@... http://helma.org/mailman/listinfo/helma-dev |
| Free Forum Powered by Nabble | Forum Help |