[Feature Request] option of storing RSS items in database

[hellodword]

Similar with https://github.com/indes/flowerss-bot/blob/fce133ddf99f56e8dd6b0f332dfdf42551939f34/internal/model/content.go

In my opinion:

• telegram is not a reliable storage, we may lose our account and all messages
• RSS feeds are always unstable, maybe impossible to restore data from them

With this feature, we can always backup our data.

[Rongronggg9]

Similar with indes/flowerss-bot@fce133d/internal/model/content.go

Not really.

https://github.com/indes/flowerss-bot/blob/fce133ddf99f56e8dd6b0f332dfdf42551939f34/internal/model/content.go#L10

	Description  string `gorm:"-"` //ignore to db

flowerss-bot does not store the description (or content, post, summary, or whatever you'd like to call it) in the database. But obviously, the imagined worst situation requires this to be stored.

With this feature, we can always backup our data.

Yes, and no. If all you needed was stored in the database, how would you restore "your data" into a human-readable form? Would you write a complicated script to transform the database into RSS files, only to import them into another RSS reader/aggregator, if the imagined worst situation were to happen?

IMHO, if you do be a data hamster, simply export your subscription into an OPML file, and import it into another RSS reader/aggregator, letting the latter fetch feeds frequently. As long as you do this, you wouldn't need to do anything even if the imagined worst situation were to happen.

Some reasonable use cases (e.g. #381) already require storing more (not all!) information on RSS items in the database. But IMHO neither your use case (storing RSS items just as a backup) nor your demand (storing almost everything, including the description, of RSS items) is reasonable.

FYI:
The public demo of flowerss-bot has shut down for four years. The direct cause was that the disk was full. I highly suspect the root cause was it stored too much information on RSS items.