juntagrico release 1.4 removes the extrasubscription entities und makes extrasubscriptions normal subscription parts (see juntagrico/juntagrico#258).
In juntagrico_billing the items on a bill currently reference subscription- and extrasubscription-types.
As extrasubscription-types are removed with juntagrico 1.4, we need to change this referencing and migrate existing bill items.
As the referencing of subscription- and extrasubscription-types was a poor design decision anyway, we will change the bill items to refence subscription-parts instead of types, which make a lot of code easier.
Bill items
Bill Items get a new ForeignKeyField subscription_part.
There are now only 2 kinds of BillItems:
BillItem referencing a subscription part, e.g. subscription or extra subscriptions
BillItem referencing a custom item type, e.g. some manual part of a bill
Existing BillItems referencing subscription types are migrated by looking for a subscription part for the same member. This is possible as long as there is still only 1 billed subscription (not extra subscription) per member.
Existing BillItems referencing extrasubscription are migrated to subscription parts by looking up (member, name) pairs).
Extra subscription accounts
The ExtraSubscriptionCategoryAccount existed to be able to assign a booking account to extrasubscriptions based on their category.
These entities are migrated to SubscriptionTypeAccount entities as the extrasubscription newly is a normal subscription.
data migration
The migration in juntagrico_billing comes in 3 steps:
pre_1_4: introduce new fields and models, without removing the older structures
data_1_4: do the migration of existing data
post_1_4: remove the unneeded older structures
The migration must be performed manually because it is not possible to enforce a certain sequence of migrations steps spanning multiple apps.
To perform the migration, the following steps have to be performed:
manage.py migrate juntagrico 0032_data_1_4 performs juntagrico migrations up to data migration
manage.py migrate juntagrico_billing performs all billing migrations
manage.py migrate performs remaining migrations, including juntagrico post_1_4
migrations squashed
Due to the manual steps, theses migrations cannot be left in the source code, as they cannot be automatically applied (eg when running unit tests).
I squashed all the migrations up to and including 0012_post_1_4 into a new migration called 0001_squashed_0012_post_1_4 and deleted all the old migrations modules.
juntagrico release 1.4 removes the extrasubscription entities und makes extrasubscriptions normal subscription parts (see juntagrico/juntagrico#258).
In juntagrico_billing the items on a bill currently reference subscription- and extrasubscription-types. As extrasubscription-types are removed with juntagrico 1.4, we need to change this referencing and migrate existing bill items.
As the referencing of subscription- and extrasubscription-types was a poor design decision anyway, we will change the bill items to refence subscription-parts instead of types, which make a lot of code easier.
Bill items
Bill Items get a new ForeignKeyField
subscription_part. There are now only 2 kinds of BillItems:Existing BillItems referencing subscription types are migrated by looking for a subscription part for the same member. This is possible as long as there is still only 1 billed subscription (not extra subscription) per member.
Existing BillItems referencing extrasubscription are migrated to subscription parts by looking up (member, name) pairs).
Extra subscription accounts
The
ExtraSubscriptionCategoryAccountexisted to be able to assign a booking account to extrasubscriptions based on their category. These entities are migrated toSubscriptionTypeAccountentities as the extrasubscription newly is a normal subscription.data migration
The migration in juntagrico_billing comes in 3 steps:
The migration must be performed manually because it is not possible to enforce a certain sequence of migrations steps spanning multiple apps.
To perform the migration, the following steps have to be performed:
migrations squashed
Due to the manual steps, theses migrations cannot be left in the source code, as they cannot be automatically applied (eg when running unit tests). I squashed all the migrations up to and including 0012_post_1_4 into a new migration called 0001_squashed_0012_post_1_4 and deleted all the old migrations modules.