Drupal 7 is a great improvement over 6, I can't wait for it to be released. However it's progress is eclipsing what could be an even greater improvement to the Drupal ecosystem and that is Views 3
Views is one of the most popular and most useful Drupal modules. Views 2 allows a huge amount of flexibility. Views 3 takes this to an almost unbelievable level.
However the documentation is still catching up. One of the features which has been added is support for SQL group by clauses.
The feature was added in "Enhance Views to support proper GROUP BY queries" if you read the thread all the way through and the code you can get an idea what is going on. Or you can read the rest of this post, which should explain it much more quickly.
When you create your view one of the options in the "Advanced Settings" is "Use Grouping", you can edit this to change the view to use grouping.
WARNING unlike most other options in views, the use grouping option is not overridable, that is it will affect every display in a view. This is often not what you want, so you may have to clone an existing view before you do this.
Once you have done this your fields will have an options cog next to them, this allows you to select the grouping options.
Group results together is a standard Group By clause, Others are also standard sql aggregate functions, obviously you should be careful not to use them for fields types which make no sense. Average on a string will throw an error.
You can also use these grouping functions for sorting and for filters. Which uses the SQL HAVING clause.
Once you have tried this a little I am sure you will get the hang of it. If you are used to the Views UI there is very little extra to learn.
I have been working on Drupal 7 sites for a while now, mostly on research projects. I like a lot of the D7 features, and think it is a big step forward over Drupal 6, which wasn't bad to begin with. Most of my work on D7 won’t have modules which will go on Drupal.org, being 'closed' or at least too specific. So I was pleasantly surprised when I was working on a side project to see an opportunity to give a little code back.
Drupal 7 allows modules to define libraries, this solves a few problems which have existed. It allows new libraries to be added and shared easily and defines dependencies between libraries. All in all it is a very nice little addition, and makes life a lot easier than working out which js and css need to be added to get particular feature working.
I was working on something which was using the google data and visualisation libraries. It was easy enough to add some code inline to include these libraries. But as you need to add a domain specific api key this would make the code a little nasty unless I put in a configuration page.
When I got to that point, I realised that there may be several modules which would require the same key, so clicked that this could be a good use for libraries. So I created the google api libraries module.
I think as Drupal 7 matures there will be many more modules which provide common libraries. The difficulty will be standardizing them. I would like to see some discussion about naming conventions for such libraries and a little checking that where a library is available a module uses it rather than including files directly.
It may be possible to create a meta library, which module developers can use to see if a particular file is included, certainly the structure of hook_library() lends itself to creating searchable data. Maybe something for the future...
XML gets a bad rap from time to time, some criticisms against it are fair, most of the time it is people seem to complain about a bad application of XML and confuse that with the mark-up being bad.
Sometimes though it is just brilliant,
the inclusion of GEO data in RSS is such a time. Why do I like this so. Well like a lot of RSS parsers I was completely unaware of the spec until about a week ago. That is kind of the point of namespaces, if you don’t understand something, you can ignore it without harm. So there have been all of these RSS feeds with geo information in and nothing broke most people will probably never notice the difference but if someone is interested they can now find GEO data in RSS feeds.
The other thing which is also brilliant is that there doesn’t need to be just one way of doing things. While working out why the geo data wasn’t working in my foursqare feed (turned out it was a problem with the feed) I looked into the simplepie file. I realised there were two standards georrs and w3c_basic_geo. OK one would be simpler but as they are standards with publicised schemas it is easy to interpret them. You can pick and choose what you want to interpret if another standard comes along it won’t break anything and you can choose to support it if you want.
Finally of course (and also brilliant) is that this GEO data doesn’t have to be part of a RSS feed. I could have some completely bespoke XML schema for, say recording narratives in RDF, and add geo data too it in a standard universally understood way.