Difference between revisions of "Cldversion"
From Dreamwidth Notes
(Created page with "In case you wanted to know about cldversion 4: 2011 Oct 12/13, GMT -7 [23:33] <Afuna> V_PauAmma_V: Why do we use cldversion 4 for new userprops we add? [23:34] <Afuna> (home i...") |
|||
| Line 2: | Line 2: | ||
| − | 2011 Oct 12/13, GMT -7 | + | <pre>2011 Oct 12/13, GMT -7 |
[23:33] <Afuna> V_PauAmma_V: Why do we use cldversion 4 for new userprops we add? | [23:33] <Afuna> V_PauAmma_V: Why do we use cldversion 4 for new userprops we add? | ||
[23:34] <Afuna> (home in about 10 hours! airport ATM) | [23:34] <Afuna> (home in about 10 hours! airport ATM) | ||
| Line 10: | Line 10: | ||
[00:10] <xb95> hee hee cldversion | [00:10] <xb95> hee hee cldversion | ||
| − | [00:11] <xb95> cldversion is supposed to indicate which dversion that prop was clustered in | + | [00:11] <xb95> cldversion is supposed to indicate which dversion that prop was |
| − | [00:11] <xb95> dversion 4 was the big migration from the global property table to the clustered property tables | + | clustered in |
| − | [00:11] <xb95> after dversion 4, I don't think we ever had to migrate a global prop to become clustered | + | [00:11] <xb95> dversion 4 was the big migration from the global property table to |
| − | [00:11] <xb95> but in theory, if you had to move, say, s2style from the global list and make it clustered, you would have to roll a new dversion | + | the clustered property tables |
| + | [00:11] <xb95> after dversion 4, I don't think we ever had to migrate a global | ||
| + | prop to become clustered | ||
| + | [00:11] <xb95> but in theory, if you had to move, say, s2style from the global | ||
| + | list and make it clustered, you would have to roll a new dversion | ||
[00:12] <xb95> then you'd set cldversion = $new_dversion | [00:12] <xb95> then you'd set cldversion = $new_dversion | ||
| − | [00:12] <xb95> and the system should understand that if a user is on dversion < $new_dversion, that prop is global, else, it's clustered | + | [00:12] <xb95> and the system should understand that if a user is on |
| − | [00:12] <xb95> in reality, I think that code has probably bitrotted pretty badly and is non-existant now | + | dversion < $new_dversion, that prop is global, else, it's clustered |
| − | [00:12] <xb95> this has been your history lesson of the day! | + | [00:12] <xb95> in reality, I think that code has probably bitrotted pretty badly |
| + | and is non-existant now | ||
| + | [00:12] <xb95> this has been your history lesson of the day!</pre> | ||
Revision as of 07:19, 13 October 2011
In case you wanted to know about cldversion 4:
2011 Oct 12/13, GMT -7 [23:33] <Afuna> V_PauAmma_V: Why do we use cldversion 4 for new userprops we add? [23:34] <Afuna> (home in about 10 hours! airport ATM) [23:34] <exor674> I don't think anything ever actually checks that [23:36] <Afuna> hee ok [00:10] <xb95> hee hee cldversion [00:11] <xb95> cldversion is supposed to indicate which dversion that prop was clustered in [00:11] <xb95> dversion 4 was the big migration from the global property table to the clustered property tables [00:11] <xb95> after dversion 4, I don't think we ever had to migrate a global prop to become clustered [00:11] <xb95> but in theory, if you had to move, say, s2style from the global list and make it clustered, you would have to roll a new dversion [00:12] <xb95> then you'd set cldversion = $new_dversion [00:12] <xb95> and the system should understand that if a user is on dversion < $new_dversion, that prop is global, else, it's clustered [00:12] <xb95> in reality, I think that code has probably bitrotted pretty badly and is non-existant now [00:12] <xb95> this has been your history lesson of the day!
