in reply to Re^2: Proposed new behaviour of isGods and isApproved (per session cache) ($NODE in key)
in thread Proposed new behaviour of isGods and isApproved (per session cache)

Well, id like to see all of the isJanitorable and CanSdcEdit and nodes of that sort change into accessrules. And in that case I'd expect to see dupe checks. For instance In the SDC nodelet youd do the check once, and then if you were on an SDC page you'd do it again. Im doubtful if we would see multiple $NODE's for the same $USER/$GROUP in a single fetch, but id be unsurprised if we saw multiple fetch for the same USER/GROUP/NODE combination. So from my POV we lose very little by including NODE in the cache and will most likely save ourself a dupe check or two.

Anyway, to explain what i have in mind ill say that id like to be able to do stuff like: 

if (isApproved($USER,'sitedocclan',$NODE) { ... }

[download]

Which would check that the user is a member of sitedocclan and that $NODE is a type editable by SiteDocClan. This would be done by putting an accessrule as the first member of the group whose code only kicked in if the $NODE parameter was defined.

Anyway, I guess my point is that id rather cache it all and see if there are issues with the cache than not cache it and later on repatch the code to return it to the current state.

Also id be very surprised if nodes like the one you mention even excersize this aspect of the design. I mean their access profile is quite easy to manage.

---
$world=~s/war/peace/g

  • Comment on Re^3: Proposed new behaviour of isGods and isApproved (per session cache) ($NODE in key)
  • Download Code

Replies are listed 'Best First'.
Re^4: Proposed new behaviour of isGods and isApproved (per session cache) ($NODE in key)
by tye (Sage) on Sep 02, 2005 at 07:37 UTC

    $NODE in key: 18 cache hits / 64 lookups
    No $NODE in key: 62 cache hits / 64 lookups

    In getting this test case ("node=re (patch)") I also noticed that %HTMLVARS is getting many large data structures left in it. So I'll add code to clean that up and deploy this weekend.

    Sorry, I got started late tonight, so I skipped my stuff so I could at least give you some test results before the next "dry spell" of me sleeping and then doing my day job, and it's already an hour past when I should be asleep.

    - tye        

[reply]

      Ok, at first i was confused by this and now I realize you were looking at the results for the case where searching occurs. Im not sure if this is an ideal case to use for comparison tho. I believe that the search routine uses CanEditNode() is not normal. Try a normal page fetch and see the results there. I think the case where search isnt invoked is by far the more common case, so speeding that up is more important than speeding up search.

      Having said that obviously you have a point, but i think maybe there is a middle ground to be found where we still cache with node, but more intelligently. IE, if a group does not contain an accessrule then the NODE is not relevent. Anyway, food for thought. :-)

      Anyway, thanks for exploring this further, I will do more as well.

      ---
      $world=~s/war/peace/g

[reply]

In Section Inner Scriptorium