NH Prof: Post v1.0 Ideas
This is just a high level list of features that I want to plug into NH Prof, now that the v1.0 mark is behind us.
- Show database query plan for statements
- Allow occasionally connected profiling, also known as production profiling – note, must be secured(!)
- Output reports as PDF/HTML
- Exporting reports
- NHibernate Search integration
- NHibernate Shards integration
This isn’t everything, but it would serve as a good place for discussion.
Licensing note: this would probably go to v1.x, which everyone who has a beta or v1.0 license can upgrade to at no additional cost.
Comments
Cool! Especially 1,2 and 5 are most appreciated!
Excuse my ignorance, but what is the difference between #1 (Show database query plan for statements) and #5 (Display query plan in the DB)?
I love the idea of #2, esp. if there would be a way to log the profiling or a way to produce periodic logs/reports.
Todd,
There isn't :-)
From where I'm sitting, number 1 is a killer feature.
If you could somehow store them and search for things like table scans - and rank, based on size of table, execution time, number of times called etc, it could be extremely useful!
Paul,
Query plans is pretty costly in terms of performance, you have to hit the DB for each query.
You also have issues with deciding things based on DB that the devs have access to vs. the production DB.
Oren,
The idea of production profiling is a great feature. Some issues only rear their ugly head once the app is under load. If there were a way to aggregate the production profiling over an extended period and then be able to analyze metrics across the aggregation; that would be a wonderful addition to an already wonderful tool. NHProf has helped me enormously in my education of NHibernate.
Just two comments?
Query plans would be a SQLServer-only feature?
2 would be a killer feature, really.
Glad to hear that NH Shards is becoming a reality!
Francisco,
I am going to try to make query plans a feature that would support SQL Server, Oracle & MySQL.
Haven't looked at it enough to tell if this is possible, but I hope so
Is support for multiple session factories dismissed completely? It's a feature that will ease essentially the use of NHProf with our projects...
I've seen that you have issues with how NHibernate works, so this isn't possible at the moment. Are you going to fix that any time soon?
Valeriu,
Define support for multiple session factories, please.
Ayende, here you go:
As an application developer:
when a ISessionFactory is instantiated (first one, second, n-th) i want to
when having multiple instances of ISessionFactories i want to
differentiate them by "assigned" name or database name.
clearly view statistics of any selected Session Factory
see which session factory was used to create any particular session.
see all sessions of one session factory grouped together
have connection strings to be set for each of session factories
May be more requirements can be formulated, but having factory statistics and grouping session by factory are the features we definitely would like to have.
It's OK also to have to write an "adapter/provider" for that, so it can help profiler figure that out.
Db query plans would be superb
How about autoupdate (for 1.x and build releases)?
Anders,
auto update is already there.
Ayende, about query plan
won't it fit a sister NH project, providing a generic RDBMS abstraction over query plan information?
Otherwise, the features looks good, maybe it would be better to have a stable (and documented) intermediate format for exports and let the community add on top of that (PDF, HTML, etc.) instead of supporting theses right from the application (which imply more dependencies for some formats)
Gauthier,
Yes, it would probably be easier to just output XML and let someone else worry about this. I might try crowd sourcing it.
About the query plan idea, I am not sure what you mean by a sister project.
On the query plan / NH sister project, (prepare to steer away from the contents of the post) the idea would be to have a NH contrib or subproject building an abstraction about how a query plan should be exposed to a reporting API, it looks pretty much like a n-tree with some semantics about costs and operations (I'm over simplifying)
With a rough idea of this abstraction in place, it should be possible to start working on baremetal implementations to perform query plan and parse it into this n-tree for several DB implementations.
On the same verge, there was this interesting work:
fabiomaulo.blogspot.com/.../...-management-in.html
I think NHibernate may provide (sometime in future) a generic abstraction layer over things like FK constraint failure, named check constraint failure, etc.
All of this is from a "coward" user point of view so I'm not in position to contribute a patch, however you could as well demonstrate why such ideas are crazy / YAGNI
Gauthier,
I am not sure what NH is supposed to do with a query plan. It is not its job.
We already provide the abstraction layer, with the exception management scheme.
Just bought NH Prof - lovely tool.
Here's a thing I'd love which would be a big win for me but hopefully not that difficult for you - the ability to name the session in the session pane. While showing new devs the features of NH in general, it would be useful to change code and label what we were doing at the time, then compare and contrast. ANTS profiler allows naming sections of your session and it's one of my most treasured features (even when not teaching new devs).
Russell,
This is something that we actually did have at some point. I'll add it again
Actually, would be even nicer if we could name sessions through code by either telling a logger or NHProf's own statics that we're about to do so. Getting pressure to provide DBAs with a "data access catalogue" that help with their tuning concerns, and we already have a lot of Fluent NH "PersistenceSpecification"-style tests, so it would be great to be able to say "and the next session is how we store and retrieve object X".
Perhaps there would be problems with thread safety here, but in this case where it's a single test runner thread the wins would be large for us.