Difference between revisions of "User:Lmat"
(→The New Plan: Answer question) |
|||
| Line 24: | Line 24: | ||
If books are created in 2.7.2, then edited in 2.6.18 to make a mixed-import-map situation, then loaded in the new 2.7 release, what should happen? | If books are created in 2.7.2, then edited in 2.6.18 to make a mixed-import-map situation, then loaded in the new 2.7 release, what should happen? | ||
| + | |||
| + | '''gjanssens''': When the feature flag protection is properly implemented this can't happen. If the books are created with 2.7.2 '''and''' the user has created bayesian imap entries in that version, GNC_FEATURE_FLAT_GUID_BAYESIAN will be set. When you then try to open that book with 2.6.18, it will refuse to do so because 2.6.18 doesn't know this feature. So in this case 2.6.18 can't create a mixed-import-map situation any more. If on the other hand 2.7.2 didn't add guid based import maps the feature flag won't be set by 2.7.2. This means gnucash 2.6.18 will be able to open this file as there is no data format conflict. If subsequently the user adds import maps in 2.6.18, they will '''all''' be in the old format. A subsequent run of 2.7.2 on that file will then find account name based import maps in in it while GNC_FEATURE_FLAT_GUID_BAYESIAN not set. Hence it will run a conversion of all import maps '''and''' set the feature flag. From that point on the file will no longer be opened by 2.6.18 (full circle). Note it's crucial here the feature flag should only be set if there actually are flat/guid based import maps in the data file. Otherwise you'd be preventing 2.6.18 from reading the file even if it didn't have any import maps at all. Yet in that case the file is perfectly readable by 2.6.18 and the user should be allowed to do so. | ||
----- | ----- | ||
Revision as of 21:42, 4 December 2017
Bayes GUID Work
| Version | Behavior |
|---|---|
| 2.7.2 | Converts bayes import map to GUID, and sets GNC_FEATURE_GUID_BAYESIAN. Reads and writes only GUIDs. Sets the GUID_BAYESIAN feature when the conversion is run, or anything is added to the import map. |
| 2.6.18 | When reading the import map, if a record is found under account name, it will be used, otherwise if an account is found by GUID, it will be used. When writing to the import map, if a slot is not found under the account name but is found under the GUID, the GUID record is used. |
The Old Plan
In the next 2.7 release (2.7.3?), if GNC_FEATURE_GUID_BAYESIAN is not set, a conversion will take place to change all the import maps to guid and flat[1]. Only this 2.7 release will set the feature flat.
The next 2.6 release (2.6.19?), when GNC_FEATURE_GUID_BAYESIAN is set, all reads and writes will be done in the new style. If it is not, all reads and writes will be in the old style.
The Problem
If books are created in 2.7.2, then bayes entries are added in 2.6.18, the import map will be mixed. If this is then read by either the new 2.7 release or the new 2.6 release, they will fail to get all information.
The New Plan
The next 2.7 release (2.7.3?) should have a new feature: GNC_FEATURE_FLAT_GUID_BAYESIAN. It will only be set by this and subsequent releases. When it is set, the import maps will be converted.
The next 2.6 release (2.6.19?) will be able to read the feature GNC_FEATURE_FLAT_GUID_BAYESIAN.
If books are created in 2.7.2, then edited in 2.6.18 to make a mixed-import-map situation, then loaded in the new 2.7 release, what should happen?
gjanssens: When the feature flag protection is properly implemented this can't happen. If the books are created with 2.7.2 and the user has created bayesian imap entries in that version, GNC_FEATURE_FLAT_GUID_BAYESIAN will be set. When you then try to open that book with 2.6.18, it will refuse to do so because 2.6.18 doesn't know this feature. So in this case 2.6.18 can't create a mixed-import-map situation any more. If on the other hand 2.7.2 didn't add guid based import maps the feature flag won't be set by 2.7.2. This means gnucash 2.6.18 will be able to open this file as there is no data format conflict. If subsequently the user adds import maps in 2.6.18, they will all be in the old format. A subsequent run of 2.7.2 on that file will then find account name based import maps in in it while GNC_FEATURE_FLAT_GUID_BAYESIAN not set. Hence it will run a conversion of all import maps and set the feature flag. From that point on the file will no longer be opened by 2.6.18 (full circle). Note it's crucial here the feature flag should only be set if there actually are flat/guid based import maps in the data file. Otherwise you'd be preventing 2.6.18 from reading the file even if it didn't have any import maps at all. Yet in that case the file is perfectly readable by 2.6.18 and the user should be allowed to do so.
- ↑ Only the bayes import maps are "flat"; the "regular" import maps retain their dimensionality.
