There are two features that I want to get done before I call a feature freeze on NH Prof and just deal with any bugs and improvements that come up until I feel it is mature enough to call it v1.0.
One of them is filtering capability. This was a pretty common request once people started realizing the kind of things that they can do with NH Prof.
Ad hoc filtering into NHibernate’s activity can bring up a lot of insight, and I certainly think that this would be an good feature to have.
The problem is that while this is a good feature, it also introduce a significant amount of complexity. This wouldn’t be a problem if the complexity was on the application side. We can deal with complexity.
The problem is that I think that this introduce a not insignificant amount of complexity into the user's’ hands. Take a look at the mock UI that I created:
This isn’t the way it will end up looking, but it is a good place to start the conversation.
What is your opinion?
More posts in "NH Prof" series:
- (09 Dec 2010) Alert on bad ‘like’ query
- (10 Dec 2009) Filter static files
- (16 Nov 2009) Exporting Reports
- (08 Oct 2009) NHibernate Search Integration
- (19 Aug 2009) Multiple Session Factory Support
- (07 Aug 2009) Diffing Sessions
- (06 Aug 2009) Capturing DDL
- (05 Aug 2009) Detect Cross Thread Session Usage
- (22 May 2009) Detecting 2nd cache collection loads
- (15 May 2009) Error Detection
- (12 May 2009) Queries by Url
- (04 Feb 2009) View Query Results
- (18 Jan 2009) Superfluous <many-to-one> update
- (18 Jan 2009) URL tracking
- (10 Jan 2009) Detecting distributed transactions (System.Transactions)
- (06 Jan 2009) The Query Cache
- (05 Jan 2009) Query Duration
- (24 Dec 2008) Unbounded result sets
- (24 Dec 2008) Row Counts