Native EOL style.
authorNick Jenkins <nickj@users.mediawiki.org>
Wed, 11 Jul 2007 07:55:24 +0000 (07:55 +0000)
committerNick Jenkins <nickj@users.mediawiki.org>
Wed, 11 Jul 2007 07:55:24 +0000 (07:55 +0000)
includes/filerepo/README
maintenance/archives/patch-archive-user-index.sql
maintenance/archives/patch-image-user-index.sql
maintenance/archives/patch-oldimage-user-index.sql

index d40eaad..03cb8b3 100644 (file)
@@ -1,41 +1,41 @@
-Some quick notes on the file/repository architecture.\r
-\r
-Functionality is, as always, driven by data model. \r
-\r
-* The repository object stores configuration information about a file storage \r
-  method.\r
-\r
-* The file object is a process-local cache of information about a particular\r
-  file.\r
-\r
-Thus the file object is the primary public entry point for obtaining information\r
-about files, since access via the file object can be cached, whereas access via\r
-the repository should not be cached.\r
-\r
-Functions which can act on any file specified in their parameters typically find\r
-their place either in the repository object, where reference to\r
-repository-specific configuration is needed, or in static members of File or\r
-FileRepo, where no such configuration is needed.\r
-\r
-File objects are generated by a factory function from the repository. The\r
-repository thus has full control over the behaviour of its subsidiary file\r
-class, since it can subclass the file class and override functionality at its\r
-whim. Thus there is no need for the File subclass to query its parent repository\r
-for information about repository-class-dependent behaviour -- the file subclass\r
-is generally fully aware of the static preferences of its repository. Limited\r
-exceptions can be made to this rule to permit sharing of functions, or perhaps\r
-even entire classes, between repositories.\r
-\r
-These rules alone still do lead to some ambiguity -- it may not be clear whether\r
-to implement some functionality in a repository function with a filename\r
-parameter, or in the file object itself. \r
-\r
-So we introduce the following rule: the file subclass is smarter than the \r
-repository subclass. The repository should in general provide a minimal API\r
-needed to access the storage backend efficiently. \r
-\r
-In particular, note that I have not implemented any database access in \r
-LocalRepo.php. LocalRepo provides only file access, and LocalFile provides \r
-database access and higher-level functions such as cache management.\r
-\r
-Tim Starling, June 2007\r
+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
index 82d98b9..62baa2d 100644 (file)
@@ -1,4 +1,4 @@
--- Adds a user,timestamp index to the archive table\r
--- Used for browsing deleted contributions and renames\r
-ALTER TABLE /*$wgDBprefix*/archive \r
-       ADD INDEX usertext_timestamp ( ar_user_text , ar_timestamp );\r
+-- 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 );
index 2205d21..db56b22 100644 (file)
@@ -1,8 +1,8 @@
--- \r
--- image-user-index.sql\r
--- \r
--- Add user/timestamp index to current image versions\r
--- \r
-\r
-ALTER TABLE /*$wgDBprefix*/image\r
-   ADD INDEX img_usertext_timestamp (img_user_text,img_timestamp);\r
+-- 
+-- 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);
index b0ba3ea..949625e 100644 (file)
@@ -1,8 +1,8 @@
--- \r
--- oldimage-user-index.sql\r
--- \r
--- Add user/timestamp index to old image versions\r
--- \r
-\r
-ALTER TABLE /*$wgDBprefix*/oldimage\r
-   ADD INDEX oi_usertext_timestamp (oi_user_text,oi_timestamp);\r
+-- 
+-- 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);