Delete feeds without subscribers

[tewe]

It looks like entries and feeds stay in the database forever. Unsubscribing just causes them to be skipped on refresh.

Even a Raspberry Pi will run for a long time before this becomes an issue.

But it is rather annoying when testing plugins. Having to wait until something new is published to the feed...

[passiomatic]

It looks like entries and feeds stay in the database forever. Unsubscribing just causes them to be skipped on refresh.

Yes, if a feed has zero subscribers or it is disabled it will be skipped on refresh.

But it is rather annoying when testing plugins. Having to wait until something new is published to the feed...

Another option would be to delete the feed when the last subscriber... unsubscribe. But I believe that the system works fine as it is now.

My suggestion while testing plugins is to use SQLite and automate the testing like this:

• setup a testing.db
• import & refresh feeds to be testing
• delete the testing.db and repeat if necessary.

This way you can be sure you always start from a clean state.

[tewe]

Importing already downloads entries, but does not run plugins, so I still have to wait

[passiomatic]

Importing already downloads entries, but does not run plugins, so I still have to wait

Yes, import from OPML also fetch feeds. This is the intended behavior. I don't understand what the problem is. Plugins are always run (see 746cdad) , if they are not then it's a bug.

[tewe]

Sorry, I was still on the issue53 branch. Maybe you should delete it now that it's merged and no longer up-to-date.

[passiomatic]

Maybe you should delete it now that it's merged and no longer up-to-date.

Done.

[passiomatic]

It looks like entries and feeds stay in the database forever. Unsubscribing just causes them to be skipped on refresh.

I investigated a bit further.

Deleting a feed if has zero subscribers makes perfect sense. However, it would be nice that while deleting a feed the related entries were automatically deleted too. As we know, to do this an "on delete cascade" constraint needs to by applied to the feed_id FK field.

As usual MySQL doesn't support the cascade behavior out of the box when using MyISAM engine, but only with the InnoDB engine. For the record: finally from MySQL 5.5 InnoDB is the default.

Adding a delete cascade behavior now to the database schema implies that existing database tables won't be updated. In the MySQL case it is even more difficult because one needs to convert a MyISAM database to a InnoDB one. A shortcut would be to export all the feed to an OPML file, create a new MySQL database and import feeds again. Problem is, you specify the engine at table level, not database level. Peewee does not enforce anything since it uses MySQL defaults. If one cannot access MySQL configuration parameters (shared hosting anyone?) tables will use the MyISAM engine for older MySQL installations.

The long term plan

Starting the next version, Coldsweat tables could have the "on delete cascade" on all relevant FK's. But even with a fresh MySQL installation that behavior is not guaranteed to work.