With hook_filter_info(), modules declare filter they provide.
Text formats are just a named, ordered collection of filters. There is not need to store filters in a DB table, as they are provided by a hook that runs once per request, and generally only a few modules provide filters. Having to join two DB tables (un-normalized), to get information we already have (or might have just by invoking a hook implemented by a few modules) is a performance issue. Also, is very hard to understand the DB structure behind the filter.module, where the concept of "filter" and "text format"are easily confused.
- Remove table {filter}
- Rename {filter_format} to {filter_text_format} and store data about text formats there.
Proposed f{filter_text_format} table structure:
- fid: Primary key, format ID.
- name: Format unique name
- filters: Serialized ordered array of filters enabled in the format
- roles: A comma-separated string of roles; references role.rid (*) There is an issue open to normalize format-roles relationship, but that is other issue.
- weight: Weight of text format to use when listing.
With this structure, this table has to be queried only once per request, to load text formats available, and the filters enabled in each one.
CRUD operations on text formats will be easier to implement and maintain. There is a real mess in this area now.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | remove-filter-table.patch | 5.69 KB | dropcube |
Comments
Comment #1
dropcube commentedWhen referencing filters, would be good to reference them by a unique string ID (filter name). So, postponed as it is dependent of #546350: Remove hardcoded numeric deltas from hook_filter_info()
Comment #2
dropcube commentedComment #3
dropcube commentedHere is a first patch, still needs work, mostly depends on #554946: Cache info from hook_filter_info() and allow to be altered
The schema changes and the update function is already implemented, but it's not worth continuing with the mess that the above issue fixes.
Comment #4
dropcube commentedComment #5
david strauss-1 Let's not increase the amount of serialized data stored outside of cache tables. If this is a cache, use the cache API. If it's canonical data, normalize it.
Comment #6
sunComing from #558666: UX/security: Revamp text format/filter configuration, and having already mentioned this to dropcube in IRC, I think we should do the following:
1) Rename {filter} to {filter_format_filter} to make clear we are storing filter data that references a certain text format (in {filter_format}).
2) Remove the serial {filter}.id column - our unique key is 'format' + 'name'. (Filters can only exist once per format)
3) Add a {filter}.status column, so we can query only enabled filters in a format.
4) Add a {filter}.settings column to store the filter's settings in the database (the filter configuration is different for each format).
Also, the {filter}.module column should stay. If a module is uninstalled, filter module's implementation of hook_modules_uninstalled() should remove obsolete data.
Comment #7
dropcube commentedMarking this issue as won't fix. Let's continue the database revamp at #559658: Store filter settings per format in {filter}