Maybe I need to dump my assumptions for a moment. Knowing the page that
we're about to be rendering from the cache would be a useful thing. Why
can't we do it? Because the performance of Page.find_by_url sucks.
I talked a little bit about that suckage a while ago, and somebody
(Adam? Sean?) suggested having a table to directly find lookup a page
from it's url from the database. I was originally dismissive, but the
idea is starting to grow on me.
- Create a page_urls table
- Whenever the slug or type of a page changes, that page and all of its
children (recursively) would update the page_urls table with their
current url(s).
If a page isn't found using a direct lookup, a regular Page.find_by_url
call would be made, so that we can still maintain all the flexibility
that provides.
Advantages of this system are:
- faster to lookup pages by url (though I don't know if it will be fast
enough that I'd want it before the cache check)
- all children of a page could be discovered recursively through:
PageUrl.find(:all, :include => :page, :conditions => 'url like ?',
"#{parent_url}%")
- old urls could be left in the table - automatically giving 'cool urls'
- unless another page comes to replace it or the page is no longer
published, a page is always available through it's old address. Old urls
would probably get a marker and redirect to the real urls of a page.
Disadvantages:
- Database isn't third normal form (the url is a calculated field, not
raw data), makes my inner database purist feel queasy.
- Long save times when slug/type changes
I should probably do some other things instead, but I might have a look
at this.
Dan.
_______________________________________________
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
