| |   |
| 171 | 171 | block and appropriate View#find options. |
| 172 | 172 | |
| 173 | 173 | 3) You may want to decode key to use with View#find(:with_keys => true) |
| 174 | Note: encode_key is not required to be a reversible operation, so |
| 175 | decode_key should just return something reasonable for your application. |
| 174 | 176 | |
| 175 | 177 | View.new do |view| |
| 176 | 178 | view.decode_key do |key| |
| … | … | |
| 180 | 180 | end |
| 181 | 181 | end |
| 182 | 182 | |
| 183 | | 4) Also, when the large set of data is stored in a distributed environment, |
| 183 | 4) Also, when a large set of data is stored in a distributed environment, |
| 184 | 184 | view list can be splitted. To optimize locality (i.e. store related data |
| 185 | 185 | in the same storage), you may specify a split hinting: |
| 186 | 186 | |
| … | … | |
| 192 | 192 | |
| 193 | 193 | This will act as an advice to split data by the key prefix. |
| 194 | 194 | Underlying storage system may either ignore it, or take it in account. |
| 195 | In any case, it is guaranteed, that splitting does not affect view results. |
| 196 | |
| 197 | |
| 198 | |
| 199 | VIEW SERIALIZATION |
| 200 | |
| 201 | View is connected with a "view document" (viewdoc). This document is |
| 202 | build up from the contents of the View.new() options (slots :name, |
| 203 | :fixed_length_key etc.) |
| 204 | When you change these slots, new version of viewdoc is created. |
| 205 | Persistant index is named after the both viewdoc UUID and viewdoc version. |
| 206 | |
| 207 | Say, when you change :fixed_length_key, old index is completely discarded |
| 208 | and new must be built. |
| 209 | Sometimes we need to do a soft migration of the current index, |
| 210 | or keep it as-is, or do a controlled migration to a completely new version. |
| 211 | Migration issues are subject to discuss. |
| 212 | |
| 213 | You may specify descriptive data for view.*{ } blocks to make them |
| 214 | "serializable". Like: |
| 215 | |
| 216 | View.new do |v| |
| 217 | v.encode_key("downcase") do |key| |
| 218 | key.downcase |
| 219 | end |
| 220 | end |
| 221 | |
| 222 | When encode_key behavior changes, you should change its description: |
| 223 | |
| 224 | View.new do |v| |
| 225 | v.encode_key("upcase") do |key| |
| 226 | key.upcase |
| 227 | end |
| 228 | end |
| 229 | |
| 230 | This will lead to using another index file. |
| 231 | In a viewdoc, such info is accessed as a regular slot: |
| 232 | |
| 233 | viewdoc["encode_key"] == "upcase" |
| 234 | |
| 235 | This is applied to "map", "encode_key", "decode_key" and "split_by". |
| 236 | |
| 237 | |
| 238 | |
| 195 | 239 | |
| 196 | 240 | |
| 197 | 241 | FURTHER DISCUSSION |
| toggle raw diff |
--- a/meta/philosophy/overview/views.txt
+++ b/meta/philosophy/overview/views.txt
@@ -171,6 +171,8 @@ In practice, you may ignore this facility and do encoding stuff in view.map
block and appropriate View#find options.
3) You may want to decode key to use with View#find(:with_keys => true)
+Note: encode_key is not required to be a reversible operation, so
+decode_key should just return something reasonable for your application.
View.new do |view|
view.decode_key do |key|
@@ -178,7 +180,7 @@ block and appropriate View#find options.
end
end
-4) Also, when the large set of data is stored in a distributed environment,
+4) Also, when a large set of data is stored in a distributed environment,
view list can be splitted. To optimize locality (i.e. store related data
in the same storage), you may specify a split hinting:
@@ -190,6 +192,50 @@ in the same storage), you may specify a split hinting:
This will act as an advice to split data by the key prefix.
Underlying storage system may either ignore it, or take it in account.
+In any case, it is guaranteed, that splitting does not affect view results.
+
+
+
+VIEW SERIALIZATION
+
+View is connected with a "view document" (viewdoc). This document is
+build up from the contents of the View.new() options (slots :name,
+:fixed_length_key etc.)
+When you change these slots, new version of viewdoc is created.
+Persistant index is named after the both viewdoc UUID and viewdoc version.
+
+Say, when you change :fixed_length_key, old index is completely discarded
+and new must be built.
+Sometimes we need to do a soft migration of the current index,
+or keep it as-is, or do a controlled migration to a completely new version.
+Migration issues are subject to discuss.
+
+You may specify descriptive data for view.*{ } blocks to make them
+"serializable". Like:
+
+ View.new do |v|
+ v.encode_key("downcase") do |key|
+ key.downcase
+ end
+ end
+
+When encode_key behavior changes, you should change its description:
+
+ View.new do |v|
+ v.encode_key("upcase") do |key|
+ key.upcase
+ end
+ end
+
+This will lead to using another index file.
+In a viewdoc, such info is accessed as a regular slot:
+
+ viewdoc["encode_key"] == "upcase"
+
+This is applied to "map", "encode_key", "decode_key" and "split_by".
+
+
+
FURTHER DISCUSSION |