Allen Gilliland wrote: > I am actually getting a number of errors from the current trunk. > > 1. there is a build error in SyncWebsitesTask.
This is fixed. > > 2. there is a classcast exception being thrown from weblog page cache > and weblog feed cache. I could not replicate this, would you mind sending me a stack trace? > > 3. there seems to be a sql error coming from the way the getHotTags > query is structured ... This is also fixed. Although I'm not happy with the solution. I did what was done in other queries where we hope that the alias used by the hibernate compiler will not change across versions and order by that, because MySQL (your version, not mine) did not support aggregates in the order by clause. > > 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 >
