From 6a18398614f04ebe8ecd53984072e7382a88d7f3 Mon Sep 17 00:00:00 2001 From: Nick Jenkins Date: Wed, 11 Jul 2007 07:55:24 +0000 Subject: [PATCH] Native EOL style. --- includes/filerepo/README | 82 +++++++++---------- .../archives/patch-archive-user-index.sql | 8 +- .../archives/patch-image-user-index.sql | 16 ++-- .../archives/patch-oldimage-user-index.sql | 16 ++-- 4 files changed, 61 insertions(+), 61 deletions(-) diff --git a/includes/filerepo/README b/includes/filerepo/README index d40eaadad0..03cb8b3ba7 100644 --- a/includes/filerepo/README +++ b/includes/filerepo/README @@ -1,41 +1,41 @@ -Some quick notes on the file/repository architecture. - -Functionality is, as always, driven by data model. - -* The repository object stores configuration information about a file storage - method. - -* The file object is a process-local cache of information about a particular - file. - -Thus the file object is the primary public entry point for obtaining information -about files, since access via the file object can be cached, whereas access via -the repository should not be cached. - -Functions which can act on any file specified in their parameters typically find -their place either in the repository object, where reference to -repository-specific configuration is needed, or in static members of File or -FileRepo, where no such configuration is needed. - -File objects are generated by a factory function from the repository. The -repository thus has full control over the behaviour of its subsidiary file -class, since it can subclass the file class and override functionality at its -whim. Thus there is no need for the File subclass to query its parent repository -for information about repository-class-dependent behaviour -- the file subclass -is generally fully aware of the static preferences of its repository. Limited -exceptions can be made to this rule to permit sharing of functions, or perhaps -even entire classes, between repositories. - -These rules alone still do lead to some ambiguity -- it may not be clear whether -to implement some functionality in a repository function with a filename -parameter, or in the file object itself. - -So we introduce the following rule: the file subclass is smarter than the -repository subclass. The repository should in general provide a minimal API -needed to access the storage backend efficiently. - -In particular, note that I have not implemented any database access in -LocalRepo.php. LocalRepo provides only file access, and LocalFile provides -database access and higher-level functions such as cache management. - -Tim Starling, June 2007 +Some quick notes on the file/repository architecture. + +Functionality is, as always, driven by data model. + +* The repository object stores configuration information about a file storage + method. + +* The file object is a process-local cache of information about a particular + file. + +Thus the file object is the primary public entry point for obtaining information +about files, since access via the file object can be cached, whereas access via +the repository should not be cached. + +Functions which can act on any file specified in their parameters typically find +their place either in the repository object, where reference to +repository-specific configuration is needed, or in static members of File or +FileRepo, where no such configuration is needed. + +File objects are generated by a factory function from the repository. The +repository thus has full control over the behaviour of its subsidiary file +class, since it can subclass the file class and override functionality at its +whim. Thus there is no need for the File subclass to query its parent repository +for information about repository-class-dependent behaviour -- the file subclass +is generally fully aware of the static preferences of its repository. Limited +exceptions can be made to this rule to permit sharing of functions, or perhaps +even entire classes, between repositories. + +These rules alone still do lead to some ambiguity -- it may not be clear whether +to implement some functionality in a repository function with a filename +parameter, or in the file object itself. + +So we introduce the following rule: the file subclass is smarter than the +repository subclass. The repository should in general provide a minimal API +needed to access the storage backend efficiently. + +In particular, note that I have not implemented any database access in +LocalRepo.php. LocalRepo provides only file access, and LocalFile provides +database access and higher-level functions such as cache management. + +Tim Starling, June 2007 diff --git a/maintenance/archives/patch-archive-user-index.sql b/maintenance/archives/patch-archive-user-index.sql index 82d98b962a..62baa2ddc2 100644 --- a/maintenance/archives/patch-archive-user-index.sql +++ b/maintenance/archives/patch-archive-user-index.sql @@ -1,4 +1,4 @@ --- Adds a user,timestamp index to the archive table --- Used for browsing deleted contributions and renames -ALTER TABLE /*$wgDBprefix*/archive - ADD INDEX usertext_timestamp ( ar_user_text , ar_timestamp ); +-- Adds a user,timestamp index to the archive table +-- Used for browsing deleted contributions and renames +ALTER TABLE /*$wgDBprefix*/archive + ADD INDEX usertext_timestamp ( ar_user_text , ar_timestamp ); diff --git a/maintenance/archives/patch-image-user-index.sql b/maintenance/archives/patch-image-user-index.sql index 2205d21ba7..db56b221f8 100644 --- a/maintenance/archives/patch-image-user-index.sql +++ b/maintenance/archives/patch-image-user-index.sql @@ -1,8 +1,8 @@ --- --- image-user-index.sql --- --- Add user/timestamp index to current image versions --- - -ALTER TABLE /*$wgDBprefix*/image - ADD INDEX img_usertext_timestamp (img_user_text,img_timestamp); +-- +-- image-user-index.sql +-- +-- Add user/timestamp index to current image versions +-- + +ALTER TABLE /*$wgDBprefix*/image + ADD INDEX img_usertext_timestamp (img_user_text,img_timestamp); diff --git a/maintenance/archives/patch-oldimage-user-index.sql b/maintenance/archives/patch-oldimage-user-index.sql index b0ba3ea762..949625eb15 100644 --- a/maintenance/archives/patch-oldimage-user-index.sql +++ b/maintenance/archives/patch-oldimage-user-index.sql @@ -1,8 +1,8 @@ --- --- oldimage-user-index.sql --- --- Add user/timestamp index to old image versions --- - -ALTER TABLE /*$wgDBprefix*/oldimage - ADD INDEX oi_usertext_timestamp (oi_user_text,oi_timestamp); +-- +-- oldimage-user-index.sql +-- +-- Add user/timestamp index to old image versions +-- + +ALTER TABLE /*$wgDBprefix*/oldimage + ADD INDEX oi_usertext_timestamp (oi_user_text,oi_timestamp); -- 2.20.1