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