Confirmed users
595
edits
No edit summary |
No edit summary |
||
| Line 124: | Line 124: | ||
What if the user bookmarks a site? Most likely we should mark the site as no more private and save its history (this would be easy, changing the private value before adding the bookmark) | What if the user bookmarks a site? Most likely we should mark the site as no more private and save its history (this would be easy, changing the private value before adding the bookmark) | ||
=== Use a Preordered Nested Tree table schema for bookmarks === | |||
* Bugs: | |||
** {{bug|408991}} | |||
* Ideas: | |||
** change bookmarks table to a preordered nested tree schema | |||
* Needs: | |||
** cleaner table (no tags, no livemarks children, no keywords) | |||
*Pros: | |||
** non recursive queries to get ancestors/descendants | |||
** fast children count | |||
** not possible to create cycles between folders | |||
* Cons: | |||
** needs 2 new columns | |||
** inserts require updating more then one item | |||
Nested Trees are a good way to manage a hierachy in sql, you can most likely select anything with one query, and no recursion is needed at all. So you can with one query know if a node is descendant or ancestor of another one. | |||
On the other side, when inserting a new node, we will have to update other nodes too, so inserts could be a bit slower. | |||
=== Add a more referer-like column to history === | |||
* Ideas: | |||
** add a column reporting the last valid visit that brought us to a page | |||
*Pros: | |||
** useful for extensions and security checks | |||
* Cons: | |||
** needs 1 new column | |||
Actually from_visit reports the page we have come from, so in case of a double redirect we would have to recurse twice to go to the original site. | |||
It would be nice having a new column reporting the real referer, or a new table schema allowing to query without recursion (a tree like schema could do the trick, but would make inserts a bit slower) | |||