I am actually getting a number of errors from the current trunk.
1. there is a build error in SyncWebsitesTask.
2. there is a classcast exception being thrown from weblog page cache
and weblog feed cache.
3. there seems to be a sql error coming from the way the getHotTags
query is structured ...
WARN 2006-09-26 10:11:05,769 JDBCExceptionReporter:logExceptions - SQL
Error: 1111, SQLState: S1000
ERROR 2006-09-26 10:11:05,770 JDBCExceptionReporter:logExceptions -
General error message from server: "Invalid use of group function"
ERROR 2006-09-26 10:11:05,771 SiteModel:getHotTags - ERROR: fetching
site tags list
org.apache.roller.RollerException
at
org.apache.roller.business.hibernate.HibernateWeblogManagerImpl.getTags(HibernateWeblogManagerImpl.java:857)
at
org.apache.roller.ui.rendering.model.SiteModel.getHotTags(SiteModel.java:517)
Caused by: java.sql.SQLException: General error message from server:
"Invalid use of group function"
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2001)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1168)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1279)
-- Allen
Elias Torres wrote:
Tagging is definitely coming along. It's very functional, but I still
need to add fixes to the themes to create links for the tags, although
the URLs already work:
/roller/eliast/feed/entries/rss?tags=something
/roller/eliast/tags/something+bohoo
I'm assuming any other parameters would work as well.
-Elias
Allen Gilliland wrote:
[snip]
I think we may have goofed a little on one part of the proposal though,
which is the getWeblogEntriesByTags() method in WeblogManager. I think
that instead of adding that method what we really want to do is update
the existing getWeblogEntriesXXXMap() methods to support tags. The
problem with the existing method is that it returns a list, which is not
really how we do things right now, instead we return a map which has
sorted the result set by time and keyed each map entry by date. i.e. so
that each map entry is a date with a list of entries from that date.
I had mentioned it to Dave but I ran into a problem. The query (an
optimal one) was written using HQL and the current
getWeblogEntriesXXXMap() uses CriteriaAPI. I'd love help converting my
simple query to CriteriaAPI, if not, another API is more efficient.
I don't have any preference between using HQL or the CriteriaAPI, but
the root of the problem is still that we don't actually want to return
those results as a list, and that we probably need to add tags to that
getWeblogEntriesXXXMap() method anyways.
Done. I've rewritten the getWeblogEntries() to use HQL (the tests pass!)
and now we support tags everywhere (so I think). Since I've updated
Feed, Weblog, PageRequest to extract tags from the parameters. Good
call, easy to fix, saved a lot of coding by taking your advise.
Part of this decision hinges on whether or not we want to provide the
possibility of querying for a set of entries not only constrained by
tags, but also constrained by other criteria as well. i.e. entries with
tags=foo+bar and category=blah and date=200608
The way the method is setup now is pretty limiting because it only
accepts a weblog and a set of tags, so you can't limit the result set,
can't specify a time boundary, etc. I think we probably want to improve
on that and it's probably easiest to do that by adding tag support to
the existing methods.
Once we do that then I think the pager part is easier. I don't think
you need your own pager actually, I think you can just make sure that
the existing pagers are able to make use of tags. That way when someone
uses the url /tags/foo+bar you are just using the LatestPager with a
constraint to a set of tags.
I'm fine with that.
I've removed my pager and was able to reuse the rest of the
infrastructure. getWeblogEntriesByTag has been removed.
Caching is another big consideration which wasn't addressed in the
proposal at all, so we'll still have to sort that out. A basic rundown
of caching goes like this ...
Sorry. :(
there are 3 rendering caches: sitewide, weblog pages, weblog feeds.
everything from the sitewide weblog goes into that cache because it has
special considerations with the way it expires content. everything else
goes into the page and feed caches.
everything that is cached for a weblog is based off of the
weblog.lastModified attribute. if that attribute is updated then all
the content for a weblog is expired and will be rerendered on the next
request.
content is put in the caches in the same way for all 3 caches and only
the page and feed servlets use the caches. the process is basically ...
1. parse request into a version of XXXWeblogRequest object.
2. build cache key based on XXXWeblogRequest object.
3. check if cached content exists and is still valid.
4. render page (if needed)
5. cache it
you can look in the WeblogPageCache and WeblogFeedCache objects to see
how the cache key generation works, it basically just inspects the
attributes in the XXXWeblogRequest object and builds a unique string out
of it. you will definitely need to update that to make sure the cache
keys work for tags.
Thanks for the description. I'm afraid to mention this, but developers
docs would be cool for the community. I'll definitely update the cache
key generation code for tags.
agreed.
done. I have updated all of the classes involved in key generation to
include tags.
the tricky part now is figuring out how we actually want the caching to
work for tags. this is something that should probably be configurable
if at all possible. i can see people wanted to completely disable
caching for tags (possibly default?), enable it for single tags only,
etc.
For single blogs we can cache everything, the question is how to expire
site-wide tags output.
i would agree that for individual weblogs the default should probably be
to cache everything, but there are also potential risks in that. for
reasonably large sites you could quickly fill up your cache with lots of
rendered pages for tag combinations that that would only be viewed once,
i.e. if someone looked for tags=foo+bar+etc and it's unlikely many other
people looked for that exact same combo. that becomes a problem if
those pages push other important pages out of the cache.
At least I'm sorting them in the cache key generation. :)
caching for the site-wide weblog in general is pretty tricky since
technically it is supposed to respond and invalidate when *any* data in
the system changes. that's obviously not very efficient, so it may make
sense to provide some ways for people to tune that a bit. one
possibility is a forced cache time, so that pages are always used for
XXX minutes before being expired regardless of if the data changes.
heck, it may even make some sense to define a completely new cache
specifically for tag pages and feeds so that they can be treated
specially if desired.
We should definitely discuss this further.
-- Allen
let me know if you have more questions about it.
-- Allen
Happy tagging!
-Elias
