Bodhi cannot create updates with ~300 builds in them #1542
Assignees
Labels
API
Issues related to Bodhi's REST API
Backwards incompatible
The proposed change is backwards incompatible and should wait for the next major release
Crash
Issues related to an unhandled crash
Refactor
Issues that are a refactor to improve maintainability for Bodhi
Comments
bowlofeggs
added
Crash
bowlofeggs
added
API
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 21, 2019
blah blah blah fixes fedora-infra#1542 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 22, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 26, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 28, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 28, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 1, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 1, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 1, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 1, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 1, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 13, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1714 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 13, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1714 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 13, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1714 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 13, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1714 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 13, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1714 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
|
A fix for this issue is planned for inclusion in the upcoming 4.0.0 release: #3221 |
|
Bodhi 4.0.0 beta is built and deployed to staging: https://copr.fedorainfracloud.org/coprs/bowlofeggs/bodhi-pre-release |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Today a user tried to create an update with about 300ish builds and PostgreSQL was not happy about the size of the index for the title field:
We should probably work towards getting rid of the title field on the update, but that will be a backwards-incompatible API change.
The text was updated successfully, but these errors were encountered: