Giving up on Polls App

I am not going to bother posting diagnostic data, as there are plenty complaining about it.

Can anyone provide me with a code that I can use within the database to delete poll data completely?

I know from previous experience that clicking remove all data when removing an app does nothing at all, because when I have gone to install the same database errors exist.

And once again, the polls app is not just breaking during the update of the app, but also seems to happen when I try to update our Cloudron install of Nextcloud. With the same errors of duplicates postgresql: during Upgrade to version 9.0.0, there are multiple errors because of duplicate indices · Issue #4619 · nextcloud/polls · GitHub .

So for this reason, we want to delete it not just from the server but the database as well, please.

We did use this to manage an upgrade to the poll app at one point

DROP INDEX uniq_shares;
DROP INDEX uniq_token;
DROP INDEX uniq_subscription;
DROP INDEX uniq_unprocessed;
DROP INDEX uniq_watch;
DROP INDEX uniq_preferences;

So something like this to remove from the DB completely would be a great help.

hey… as i can see in your posted GH-issue a pull request has been filed to solve this problem. Which means it should be solved with the next update of poll-app.

ummm apart from that I don’t know which indices were added when installing that app. the code of that app will tell you that. you might wanna look into that yourself?

The issue is two fold and could happen with any app.

The issue is PostGreSQL using a single namespace for indices. For that to not conflict, developers needs to be very consistant when developing and naming things. For example, then naming an index, should follow some strict rules (regardless of which data base engine you use, because it is just good hygiene).

  • Name indices and tables with prefixes (like for example: oc_myap_Myindex), or
  • Name indices using a random naming (like generating a GUID).

The issues with the Polls app was not an exclusive polls app issue but more of a combination of the DB backend in use and lack of strict naming conventions.

In the GH repo under issues, I have posted how I solved this issue. You should follow that and move on.

I have rarely seen faster response time and support on any Open Source project. Ever. I would like to praise @dartcafe for hard and great work, aswell as being patient with me. :slight_smile: