-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OrganisationBoundaryReview
object can only be related to one Organisation
object and one DivisionSet
object
#2227
Comments
OrganisationBoundaryReview
object can only be related to on Organisation
object and one DivisionSet
objectOrganisationBoundaryReview
object can only be related to one Organisation
object and one DivisionSet
object
I guess it depends what the 'review' is. There's obviously a case that it's the process that gets to the legislation, but I don't know if we're that bothered about catching all the detail of that. The outcome is what we're bothered about, but we do want to track the process as it's going along too. For example the current NI review process has reports for each district (link). If we wanted to link those then we would want an Re. Wards and County Electoral Divisions I can see that there was one review that changed a parish which has knock on effects on district and county divisions, and so having 2 Maybe legislation should be what we model as it's the ultimate source of truth, and we're less interested in the process that gets us there. OTOH I quite like the idea of becoming a place people can get information about all reviews happening at different levels of electoral geography; and that feels easier to me with the |
Lets talk about this next week. I can run you through the background in more detail. The main reason I am thinking the model that [one review = one legislation] would be useful is that we don't have a unique ID for a review or ECO in the data we scrape from LGBCE, so we have to try and match up a review we've scraped from LGBCE to a record in our DB. Our current thinking is that the |
Drive by -> example of CGR affecting 2 orgs: https://www.legislation.gov.uk/uksi/2024/597/made (Uttlesford and Essex) |
More examples: North Yorkshire: https://www.legislation.gov.uk/uksi/2022/328/made These SCOs affect both county and UTA because they effectively restructure the former into the latter. In the db, currently this is reflected with two boundary review records for the same legislation. This was causing issues with boundary bot that I addressed in this PR: #2248 |
Note: these two were related to both because the old authority held shadow elections for the new one |
Currently an
OrganisationBoundaryReview
can be related to oneOrganisation
object and oneDivisionSet
object.This isn't really true in the real world though. For example
These Electoral Change Orders
https://www.legislation.gov.uk/uksi/2019/354/made
https://www.legislation.gov.uk/uksi/2019/423/made
make changes to both District Wards and County Electoral Divisions in one order, so they affect both a District and County.
This order
http://www.legislation.gov.uk/uksi/2014/270/made
re-wards the whole of Northern Ireland in a single piece of legislation so it affects 11 different districts.
and
This Boundaries Amendment Order
http://www.legislation.gov.uk/ssi/2018/308/made
(and all similar orders) necessarily affects 2 neighbouring districts.
These aren't completely isolated examples.
At the moment, the way we seem to have handled this is by creating multiple
OrganisationBoundaryReview
objects for the same legislation and then linking each one to a differentOrganisation
andDivisionSet
. Currently we're trying to sort out some duplicate records that have been incorrectly created but it is hard to work out which are the "good" dupes and which are the "bad" dupes.Do we like this model? It seems like a better model would be to allow one
OrganisationBoundaryReview
to be related to manyOrganisation
s and manyDivisionSet
s.What problems would that cause us?
The text was updated successfully, but these errors were encountered: