Skip to content
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

SQLite table for tags #736

Open
sjehuda opened this issue Apr 30, 2024 · 2 comments
Open

SQLite table for tags #736

sjehuda opened this issue Apr 30, 2024 · 2 comments

Comments

@sjehuda
Copy link
Contributor

sjehuda commented Apr 30, 2024

Feature requests

This is a proposal to add two tables to the database.

Table: Bookmarks
Columns: Bookmark_ID, Bookmark_Title, ...

Table: Tags
Columns: Tag_ID, Tag_Name

Table: Bookmarks_Tags
Columns: Bookmark_ID, Tag_ID

This should be storage wise and accelerate queries.

See my implementation at Slixfeed/sqlite.py

        tagged_feeds_table_sql = (
            """
            CREATE TABLE IF NOT EXISTS tagged_feeds (
                id INTEGER NOT NULL,
                feed_id INTEGER NOT NULL,
                tag_id INTEGER NOT NULL,
                FOREIGN KEY ("feed_id") REFERENCES "feeds" ("id")
                  ON UPDATE CASCADE
                  ON DELETE CASCADE,
                FOREIGN KEY ("tag_id") REFERENCES "tags" ("id")
                  ON UPDATE CASCADE
                  ON DELETE CASCADE,
                PRIMARY KEY ("id")
              );
            """
            )
@LeXofLeviafan
Copy link
Collaborator

                id INTEGER NOT NULL,
                feed_id INTEGER NOT NULL,
                tag_id INTEGER NOT NULL,
--              ...
                PRIMARY KEY ("id")

Wouldn't the primary key be normally feed_id, tag_id in such tables (without a need for a dedicated id column)?

@sjehuda
Copy link
Contributor Author

sjehuda commented Apr 30, 2024

Yes, and I think this is what Liferea does too.

I am not an expert, so please do not consider my advises fully.


If we do this, loading of tags will be faster, yes? See #559 #594

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants