It ain’t so simple, mister!
The most requested feature for NH Prof is the ability to view the query results inline. I created a mockup just to show how this might look like. The real discussion is below the image.
On the face of it, this feature looks very simple. Query the database, throw the results into a grid, done. It is actually not that simple. Let me enumerate all the things that complicate this feature.
The simplest thing is a big stumbling block. How do I get the connection string?
I can make the profiler figure out what the connection string is on the profiled application. That is a relatively simple task from technical perspective. It also open up a whole can of worms. Connection strings are a considered to be highly valuable, and getting the connection string from a running application is a big No! from the security & regulatory perspective.
And that is assuming that I can actually make use of the connection string. In many cases, the connection string point to a database that is not accessible from a developer machine, or not accessible as the database user.
So we remove the “auto detect connection string” feature and move to the next issue. I am not supporting just SQL Server. I am aiming to support all major databases that NHibernate support. But you cannot connect to a MySQL database (to take a non random example) without referencing MySQL’s dlls. Am I suppose to take a dependency on all possible drivers? For that matter, I simply cannot distribute those drivers with NH Prof. MySQL’s drivers are GPL. As such, they are inherently incompatible with commercial software.
So now I need to dynamically discover and load dlls. And that probably involves some sort of UI to search for them, and error handling for all sorts of interesting problems.
Then we have additional issues. What happen if you try to see the results of a DELETE statement? Or execute some sensitive stored procedure.
None of those issues are impossible to resolve, they are just things that complicate a relatively simple feature and make it much more complex.
Comments
Once you are in the process space of the application (since you appender lives there too) can you not access the SessionFatory created from NHibernate and then simply open a connection from there?
I _could_.
But that make a lot of assumptions.
1) that I am actually in that process space. NH Prof is also supporting profiling from a file or from a standard unmodified installation.
2) that this is actually allowed by the customer. See arguments about security in the post.
3) that there is only one session factory in the aplication.
Why don't dont support both?
If an option is in NHProf is explicit set and all above assumptions are fine, allow direct execution of the result. Or direct execute all querys and store them in the session file for later reuse. This have the benefit that i have exact the data which are there at profile time.
And second, allow the user to put a simple xml/config file at the position where the appender lives or at the root of the application where i can store my connection strings (for each session fatory name) explicit for NHProf. If it is there NProf could copy its values to the session file.
I for myself dose not need the results inline. I prefer to have a tab for that data beside the details tab.
Steve,
You just suggested adding more complexity.
I don't want to have more than a single way of doing this.
Ok, but consider to allow this configuration on an per application base. Because i dont want to change the connection string if i have to profile more the one app on a short time.
While this would be cool - seems a bridge too far. Not even in SQL Profiler do I get a tooltip or whatever of the results - probably for some pretty good reasons.
The issue, as well, is that some people will want what the query would have produced at that point in time - which unless you store results on a stack somewhere, will be inaccurate as queries go by and change the database.
The only thing I can think of is a setting to set up a preview configuration that is defaulted in certain scenarios where it is feasible. And even then, this feature too much. Having it very easy to get what the query was seems like more than enough.
Ahh the beauty of shrinkwrap that interacts with 3rd party. Been there done that.
10% feature, 90% handling related issues that have nothing to do with feature you are implementing.
It's a drag, but we're confident you can pull it off.
I have no idea how you detect the SQL queries that are run in NHibernate, but can't you use the same methods to see the results? I know as a user I'd prefer to see the (stale) results that were actually there when the application was run and not the current results which may have changed...
Why don't you try something like enumerating a list of the system DSN's the user has created in their Data Sources (ODBC) control panel? That pushes the responsibility off onto the user for managing drivers, how to connect, what to connect to, etc.
I know this isn't completely on topic, but I guess if you decide to implement this feature, it's better to put results view under the sql statement details view.
I think there are more issues with this than you're even describing. Most likely people want to see the results that the query itself returned, right? I think this is impossible by using an external connection.
There are too many race conditions involved if you plan to re-run the same query as the profiled application. If they are modifying objects at the same time that queries are running (seems logical for lots of applications) by the time you run the same query they could have changed the data out from under you.
Would people really just want to run the query on the current data? What value would that provide? If that's the case, make it easy for them to copy and paste the sql statement so they can run it in their own query tool.
MySQL Drivers being GPL is not counter to this being a production / commercial application as long as you are not changing the 'compiled' code using the source of the connection logic. The GPL doesn't force you to 'reveal' your SOURCE unless you have modified the GPL items for inclusion. Since in this case you would be using the Compiled DLLs no harm no foul - but still better to check with the MySQL folk and the legal eagles - but It seems that overall precedent is that linking to a compiled item is not enough under the GPL to cause 'full code disclosure' of the code including the GPLed item.
Just thought I would point that out.
Thanks,
Joe,
I am sorry, but what you are talking about is the Lesser GPL.
GPL code requires that you would GPL your own code for the mere use of GPL code.
That includes merely linking to the GPL code.
does that mean i can't use mysql and/or mysql drivers for any application without making the source code available?
k03123,
Yes, that is what it usually means.
At least not if you distribute it.
@k03123
Welcome to the "GPL free world"....
@Ayende
I guess MySQL drivers exists in dual licence, to allow you to distribute it with your application without the gpl restriction, of course, you need to "licence" it for that.
I actually was thinking I wanted this feature just last week. However, I really see this as a SoC issue. It is not NHProfilers job to show me the results, it is its job to simply profile my app and let me know where i screwed up.
If i want to get the resulting output i can simply copy the sql and past into a query window. about the only feature I would want NHProfiler to do is maybe may the copy part easy say with a button.
Comment preview