Feature Proposal: Store creator and create date in metadata to improve performance

Motivation

Copied from Tasks.Item9332

SEARCH is happy to return $creator and $createdate but it has to get that information from the version control system. It would be very handy to have this info stored in the Meta Data (along with most recent author/mod date).

In large webs, asking for creator/date slows things down. Asking for "find me all of the pages I created" is slower yet.

A quick save at creation time (new pages) or edit time (pages that don;t have this data yet) would save a lot at SEARCH time.

-- VickiBrown - 16 Jul 2010

Description and Documentation

This is a case where the meta-data would be being used to compensate for the deficiencies in the store. My preferred approach is to fix the store, not the meta data. Ultimately I'd like to remove the TOPICINFO completely, not increase the number of fields.

However, having said that, what you suggest is certainly an option to improve performance. Please raise it as a FeatureRequest? in Development web - it's not ready to be a task yet.

-- CrawfordCurrie - 21 Jul 2010

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: VickiBrown - 12 Aug 2010

Discussion

I'm sorry if this is off-topic, but I was wondering about being able to query the createdate/creator - I can't see how to do it with VarQUERY, for example :/

-- PaulHarvey - 13 Aug 2010

%QUERY only shows what is cached in the topic metadata. Creator and createdate are not cached (nor is any other history information except current version).

-- CrawfordCurrie - 13 Aug 2010

As an option DBCachePlugin gathers createdate and createauthor.

-- MichaelDaum - 13 Aug 2010

I agree with Crawford: it's better to fix the store than making things more complex and create another source of inconsistency.

-- GilmarSantosJr - 06 Sep 2010

This was implemented in Tasks.Item10678. SvenDowideit didn't change the embeddedStoreForm to physically hold a META:CREATEINFO in the serialised .txt files, rather, the store populates when loading, and MongoDBPlugin populates it as well.

Thus I believe Gilmar's concern has been addressed (we skipped the commitment/acceptance procedure on this, if there is any concern regarding the implementation which has already been committed, I'm sure SvenDowideit and myself are willing to discuss further).

Also closes Tasks.Item10006.

-- PaulHarvey - 22 Jun 2011