Closed SanderND closed 1 year ago
So I was thinking about this is simply having a field that says what version on the army book was used sufficient or do you have to have it for every unit and upgrade?
One field saying the version, thus on the level of ARMY_UUID is fine. It's important that the way the version is written down, is relatable to the way versions are stored in the table VERSIONS in the static data. Only that way i can make a correct join to it and use the correct static data to relate to the lists.
@SanderND Ok is this different to #119 ?
The output we have to work with is
{
"validation":{
"hasError":true,
"errors":[
{
"severity":"INFO",
"message":"Army: Use version 2 Nd Edition, Version 2022 Alpha 3 Hotfix 1"
},
{
"severity":"ERROR",
"message":"Unit: Siege Weapon, invalid cost: 175, correct cost: 170"
},
{
"severity":"INFO",
"message":"Army: Characters use 1540 points"
},
{
"severity":"INFO",
"message":"Army: Core use 1129 points"
},
{
"severity":"INFO",
"message":"Army: Special use 1830 points"
}
]
},
"organisation_points":[
{
"organisation_id":398,
"points":1540
},
{
"organisation_id":399,
"points":1129
},
{
"organisation_id":400,
"points":1830
}
]
}
So just to be clear you would like a field called:
rules_version
that contains version 2 Nd Edition, Version 2022 Alpha 3 Hotfix 1
?
I need indeed one field with the rulesversion.
But: the name the formatter sends is not in line with how versions are named in the table VERSIONS. Imo, that is something that @zikum must do in order to let me successfuly make use of this new field. Also, imo its better to use an integer (eg number of a version) than a string of text as its a better basis to make a precize join to the versions table.
Op 1 sep. 2022 om 13:32 heeft Sean @.***> het volgende geschreven:
@SanderND Ok is this different to #119 ?
The output we have to work with is
'validation': {'hasError': True, 'errors': [ {'severity': 'INFO', 'message': 'Army: Use version 2 Nd Edition, Version 2022 Alpha 3 Hotfix 1'}, {'severity': 'ERROR', 'message': 'Unit: Siege Weapon, invalid cost: 175, correct cost: 170'}, {'severity': 'INFO', 'message': 'Army: Characters use 1540 points'}, {'severity': 'INFO', 'message': 'Army: Core use 1129 points'}, {'severity': 'INFO', 'message': 'Army: Special use 1830 points'}]}, 'organisation_points': [ {'organisation_id': 398, 'points': 1540}, {'organisation_id': 399, 'points': 1129}, {'organisation_id': 400, 'points': 1830}]} So just to be clear you would like a field called rules_version that contains version 2 Nd Edition, Version 2022 Alpha 3 Hotfix 1?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
The formatter is now deriving the rules version used by the lists read. This allows us to link it to the correct static data. E.g. if in rules version 1 a unit would be categorized as 'Special' and in version 2 as 'Core' this field can be used to link this correctly. Therefore, I need two things:
1) The rules version from the formatter needs to be saved into the lists table. 2) The rules version from the formatter should have a unique field to join to the static data. In the static data the information of versions are stored in e.g. table Armies, field 'subversion' but also in field 'version id' and 'released at'. I'm not sure if the version data from the formatter comes in the same way and whats the perfect way of joining the lists and static data together. Three fields with some kind of a unique ID looks a bit too much for me. Ideally is the formatter returning a Version ID which corresponds to exactly the correct version of the rules in the static data.