Hi Alex, feedback inline:
On Mon, 2010-07-12 at 12:03 +0200, "Alex J. G. Burzyński" wrote: > Hi Chantal, > > The paging problem I've asked about is that having course-event pairs > and specifying rows limits the number of pairs returned not the courses > > +-------+----------------------+------------+------------+ > | id-id | name | town | date | > +-------+----------------------+------------+------------+ > | 1-1 | Microsoft Excel | London | 2010-08-20 | > | 1-2 | Microsoft Excel | Glasgow | 2010-08-24 | > | 1-3 | Microsoft Excel | Leeds | 2010-08-28 | > | 2-1 | Microsoft Word | Aberdeen | 2010-08-21 | > | 2-2 | Microsoft Word | Reading | 2010-08-25 | > | 2-3 | Microsoft Word | London | 2010-08-29 | > | 3-1 | Microsoft Powerpoint | Birmingham | 2010-08-22 | > | 3-2 | Microsoft Powerpoint | Leeds | 2010-08-26 | > | 3-3 | Microsoft Powerpoint | Leeds | 2010-08-30 | > +-------+----------------------+------------+------------+ > > > And from UI point of view I'm returning less courses then events - > that's why I've asked about paging. > > The search for q=name:Microsoft town:Leeds with rows=2 should return: > 1-3 & 3-2 & 3-3 If you want to list all available courses in a query and also display how often and where they take place, then query for "name" (in your table") and facet on "town" per name. This might require the use of the facet.query parameter. Otherwise use your query from above and group afterwards in the client or your server backend. Of course, you should increase the rows value. But I see your point with paging, so facetting might be a better option. Or maybe field collapsing is what you need (there is a patch - search for "solr field collapsing" and you should find a lot about it). (I haven't tried that, however, and it's just a guess.) Chantal > > But 3-3 will be obviously on page 2. > > I hope that it makes my questions more clear. > > Thanks, > Alex >
