phpwiki-talk

Re: [Phpwiki-talk] browse page and plugin/WikiAdminSelect.php show different owners for a page - and sometimes neither is what I expect

[Reini U. <ru...@x-...>]

Charles Corrigan schrieb:
> On Thu, December 2, 2004 10:38, Reini Urban said:
>>Charles Corrigan schrieb:
>>>Just to clarify, I had problems with page ownership since I started
>>>playing with 1.3.11pre - my previous patches were chipping away at bits
>>>of the problem. 
>>
>>oh. Sounded like the cache problem I was working at.
>>
>>>What I am testing is from CVS as on Saturday - I will upgrade
>>>to latest over the weekend.
> 
>>You have been warned. The pagedata and versiondata cache revamp is not 
>>finished, it's dirty, and I want to clean it up without using too much 
>>memory.
> 
> With a clean install, the steps to reproduce this problem are:
> 1 - change the owner of the page PageGroupTest/Four from CarstenKlapp to
> another user
> 2 - view the page - will correctly show the new owner
> 3 - view PhpWikiAdministration/Chown - it will still show Carsten as the
> owner.

Ah, a PageGroupTest subpage! I've found out those subpages have a 
pagedata cache problem as well as importing problems.
This is on my TODO list.

> I have traced this problem through the call stack to WikiDB_Page->getOwner()
> and WikiDB_Page->get() -  get() does not find a value for 'owner' in the
> metadata of the page and it falls back to 'author_id', staring from the
> first available version of the page.

thanks, looks easy to fix.

> As Reini suggested, it does appear that this is related to caching - when
> the page is actually being displayed, all of the data is correct. However,
> when the page is referred to indirectly (via lib/plugin/WikiAdminChown.php,
> lib/plugin/WikiAdminSelect.php and lib/PageList.php in this case), the
> cached data is incorrect or incomplete.
> 
> So far, I have been working around the periphery. I do not really know how
> all of this works, so it may take me a while before I find anything. Given
> that Reini are working on the caching, is it worth me investigating further?

if you want to help I'd appreciate it.

I'm just considering putting out the _cached_html field to an extra sql 
field in the sql backends. To simplifiy the cache logic and the sql 
handling and at most to improve memory usage. This field is only needed 
for the current page, rarely used, and we could fetch it extra when 
needed. So far we fetch it, process it, store it in the pagadata cache 
and undef it then when it's not the current page. (failing memory release?)
my simplification would need to undef only for the non-sql backends.

and then I might be simplifiying version_data cache by adding some short 
logic and removing space. so far we store it twice. one version with 
content and one without.

current TODO:
FixMe:
* test httpauth, and reported personalpage auth problems
* test against php-5.x
* test against apache2 and IIS problems
* finish ModeratedPage (2/3: deferred action. mimic post somehow)
* iniconfig helpers: config.ini creation and converter,
                      install => configurator (2/3)
* wait for sf.net fc1 update.

Improvements:
* collapse page change notification on LoadAny (2/3, missing: ?)
* restrict certain action to groups: RawHtml (could be a define)
* store less versiondata_cache (memory)
* refactor _cached_html for sql backends (memory and simplification)
* more antispam
* refactor WikiDB remove to enable revert

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] browse page and plugin/WikiAdminSelect.php show different owners for a page - and sometimes neither is what I expect

[Reini U. <ru...@x-...>]

Reini Urban schrieb:
> Charles Corrigan schrieb:
>> On Thu, December 2, 2004 10:38, Reini Urban said:
>>> Charles Corrigan schrieb:
>>>
>>>> Just to clarify, I had problems with page ownership since I started
>>>> playing with 1.3.11pre - my previous patches were chipping away at bits
>>>> of the problem. 
>>>
>>> oh. Sounded like the cache problem I was working at.
>>>
>>>> What I am testing is from CVS as on Saturday - I will upgrade
>>>> to latest over the weekend.
>>
>>> You have been warned. The pagedata and versiondata cache revamp is 
>>> not finished, it's dirty, and I want to clean it up without using too 
>>> much memory.
>>
>>
>> With a clean install, the steps to reproduce this problem are:
>> 1 - change the owner of the page PageGroupTest/Four from CarstenKlapp to
>> another user
>> 2 - view the page - will correctly show the new owner
>> 3 - view PhpWikiAdministration/Chown - it will still show Carsten as the
>> owner.
> 
> Ah, a PageGroupTest subpage! I've found out those subpages have a 
> pagedata cache problem as well as importing problems.
> This is on my TODO list.

No, a much simplier explanation and solution:
The PageGroupTest* pages have wrong pgsrc definitions.
The want to be named like PageGroupTest/One, PageGroupTest/Two, but the 
basefiles miss the %2F ("/") seperator.

pagadata cache is working (just slow and not perfect yet), the reason is 
the wrong pagename.

A fix for the broken "/" detection in the PageGroup plugin is pending. 
(maybe WikiAdminSelect also, I'll investigate.)
"Owner" is now fixed. Just "Last edited ...by" is still broken.

Explanation:
I wanted to group the PageGroupTest subfiles into subpages to make use 
of subpage plugins also. But I forgot the rename the pgsrc filenames, 
just fixed the pagename meta-data and the PageGroupTest basepage content.

I backed that change now out, because we have these possible grouping 
schemas (besides the obvious Categegory links):
This experimental and tricky PageGroup plugin, and
then the possibility to group pages by subpages and the ListSubpages 
plugin.
We shouldn't mix that.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

RE: [Phpwiki-talk] browse page and plugin/WikiAdminSelect.php show different owners for a page - and sometimes neither is what I expect

[Charles C. <ch...@ru...>]

On Sat, December 4, 2004 23:01, Reini Urban said:
> > With a clean install, the steps to reproduce this problem are:
> > 1 - change the owner of the page PageGroupTest/Four from CarstenKlapp to
> > another user
> > 2 - view the page - will correctly show the new owner
> > 3 - view PhpWikiAdministration/Chown - it will still show Carsten as the
> > owner.
>
> Ah, a PageGroupTest subpage! I've found out those subpages have a 
> pagedata cache problem as well as importing problems.
> This is on my TODO list.

Great that this is caught but I think there is still a problem - I will try
to create a new testcase...

> > So far, I have been working around the periphery. I do not really know 
> > how all of this works, so it may take me a while before I find anything.

> > Given that Reini are working on the caching, is it worth me 
> > investigating further?

> if you want to help I'd appreciate it.

I have started thinking about it, see below.

> I'm just considering putting out the _cached_html field to an extra sql 
> field in the sql backends. To simplifiy the cache logic and the sql 
> handling and at most to improve memory usage. This field is only needed 
> for the current page, rarely used, and we could fetch it extra when 
> needed. So far we fetch it, process it, store it in the pagadata cache 
> and undef it then when it's not the current page. (failing memory
> release?) my simplification would need to undef only for the non-sql 
> backends.
>
> and then I might be simplifiying version_data cache by adding some short 
> logic and removing space. so far we store it twice. one version with 
> content and one without.

I started looking around. I looked at the SQL schemas and my thoughts
follow.  Please let me know if any of them make sense. If they do not make
sense, please let me know why so I will not make the same mistake again.

1 - is there a good reason to have table: recent separate from table: page?
At a first glance it looks like the 3 INTs there would be very useful in the
main page structure, would add minimal overhead to that table and would
reduce database access times (and perhaps memory) by avoiding a separate
table lookup.

2 - table: nonempty - would it be worth replacing this table with a Boolean
column in table: page? If speed is really essential, there could be a
secondary/alternate index on page consisting of column: id and (proposed)
column: nonempty.

3 - would it make sense to add column: content into table: page? While this
would require redundant storage, it would allow the usual case of displaying
a page to skip reading table: version (and table recent if option 1 does not
make sense).

4 - (alternative to option 3 but does depend on option 1 being in place)
Would it be worth removing column: pagedata from table: page and, with
column: latestversion (currently in table: recent but moved into table: page
in option 1) always query on table: page joined to table: version? So:
SELECT page.id, page.pagename, page.hist, version.version, version.mtime,
version.minor_edit, version.content, version.versiondata
FROM page, version
WHERE page.id = version.id
AND page.latestversion = version.latestversion;

Regards,
Charles