Talk:FactoidPluginRewrite
From UbuntuBots
Contents |
About the Database
Maybe we should think about not storing the value of a factoid in the "facts" table at all, but keep them in the log/history table and only store a revision ID in the facts table. Right now the "log" table holds the previous value. Something like this:
- Done, tables schemas are a bit different but is working, check Stormyfacts. M4v
facts
| Row | SQL type | Description |
|---|---|---|
| "id" | INTEGER PRIMARY KEY | Factoid ID |
| "name" | VARCHAR(20) UNIQUE NOT NULL, | Factoid name |
| "author_id" | INTEGER NOT NULL REFERENCES "users" ("id"), | ID of the autor |
| "added" | DATETIME, | Original factoid creation |
| "revision_id" | INTEGER REFERENCES "log" ("revision_id"), | Revision id |
| "flags" | TEXT | List of flags associated with the factoid |
| "popularity" | INTEGER NOT NULL DEFAULT 0 | Popularity |
log
| Row | SQL type | Description |
|---|---|---|
| "id" | INTEGER PRIMARY KEY, | Internal log ID |
| "fact_id" | INTEGER NOT NULL REFERENCES "facts" ("id"), | ID from the "facts" table |
| "revision_id" | INTEGER DEFAULT 1, | Revision ID, incremented for each revision of a factoid |
| "author_id" | INTEGER NOT NULL REFERENCES "users" ("id"), | ID of the author from "users" |
| "added" | DATETIME, | When the edit happened |
| "value" | VARCHAR(200) NOT NULL | The (new) value of the factoid |
users
| Row | SQL type | Description |
|---|---|---|
| "id" | INTEGER PRIMARY KEY, | ID of the user |
| "name" | VARCHAR(50) | Name of the user (IRC nick) |
| "capabilities" | TEXT | List of capabilities/permissions associated with this user |
Tsimpson 18:10, 3 June 2010 (UTC)
Edit Tsimpson 12:53, 6 June 2010 (UTC):
- Added "flags" to "facts";
- Added "capabilities" to "users";
Maybe we can use the "capabilities" row in "users" to do some more advanced user management without messing too much with supybot user management.
- I disagree, the users table is for track who created and edited what, without adding every hostmask string in each factoid row. I don't want to reimplement stuff that Supybot already does, and it does it well imo. We'll need to workaround testcases not working because supybot doesn't know about the plugin's capabilities and dunno what else. M4v
Factoid flags
Should the flags section for the facts database store a comma separated list or a bit-mask? Tsimpson 12:48, 6 June 2010 (UTC)
- bitmask sounds like a better idea. You can do SQL queries like "where (flags & 1)" and not "where flags like '%deleted%'" which is nicer I think M4v
- done M4v 22:09, 8 June 2010 (UTC)
Local/Global factoids
I gave up on my idea of storing local/global factoids in different tables, keeping everything in a single table makes the code a hell lot more simpler, and there's no noticeable gain nor nothing I can think that would justify using different tables. So I reverted to Encyclopedia's way. M4v
Categorized factoids
This can be done in the same fashion described for localized factoids. Each category would be a different database. This way we would only need to implement only one method and not two for localization and categories. So each channel will have a primary category, and an optional secondary for the case of a factoid that isn't in primary.
It will work in a similar way that local/global factoids, except that unlike local factoids, a category can be shared across channels. Edit capabilities should be category specific, so the maintainers of "offtopic" can't edit "support"
| channel | primary | secondary |
|---|---|---|
| #ubuntu | support | none |
| #kubuntu | support | none |
| #ubuntu-offtopic | offtopic | support |
| #ubuntu-devel | devel | none? |
| #ubuntu-es | support-es | support |
Config should be like:
- ChannelValue category.primary
- ChannelValue category.secondary
