Support for the Huagati Query Profiler, Huagati Linq-to-SQL Profiler, Huagati Entity Framework Profiler, Huagati LLBLGen Profiler
11/4/2009 2:14:17 AM
daelmo
Posts: 1
|
Hi Kristofer,
I just tried the tool. Looks great so far. I have few comments though:
- [BUG] Testing from MS UnitTest make some things don't get logged. Weird, the same code in a console or winApp works nice. Could you confirm that?
- [BUG] This code throw an exception.
Code:
using (DataAccessAdapter adapter = new DataAccessAdapter())
{
adapter.FetchEntityCollection(customers, null);
customers[0].ModifiedDate = DateTime.Now;
adapter.SaveEntity(customers[0]);
}
Note that I'm performing two actions (Fetch, then Save). Seems like when the connection is closed, the profiler stop working. If you open two separate adapters it works. It's easy to reproduce. Let me know if you want me to email you a repro solution.
- [WISHLIST] You have to put the initialization code in the DataAccessAdapter code. That isn't that great if you regenerate code in regular basis. Would be great some kind of dependency injection and scopes. The idea is plug/unplug the profiler logging on the fly. A custom LLBLGenPro template for Adapter should work as well.
- [WISHLIST] The log explorer layout is not flexible. Would be great some anchors layout and docking toolbox.
- [WISHLIST] The documentation is not extensive. Just a quick start guide and a reference manual in your blog. Those things are great, but for example, you could create your own profiler filters but the guide doesn't elaborate on that. Would be great to extend it a bit.
Hope this list make sense. Let me know if you need further info on this.
--
David Elizondo
|
|
0
• permalink
|
11/4/2009 12:09:36 PM
Kristofer Andersson
Moderator
Posts: 331
|
Hi,
Thanks for the feedback.
1) Do you have a repro for the MS UnitTest issue?
2) I have fixed the bug listed in #2; a fix for this is included in the next update. (Will be released soon, just need to go through testing first...)
3) I will look into if I can simplifying the initialization. As for plugging/unplugging on the fly I think that is best done through a app specific setting. That way logging can be turned on/off within an app by a user/admin without any code changes.
4) I will look into making the log explorer a bit more user-adjustable. Right now it is possible to customize the lower portion of the screen (where all the details for a query is listed) with templates but that part need to be documented a bit better first.
5) Better documentation is under way. 
As for customized profiler filters - it is really very simple. All you need to do is create a new class that inherits from the ProfilerFilter class and implements an override of the IsValid method. Within that method, it can inspect any member of the QueryInformation object and use that to determine if a query should be logged or not. Similarly, a filter can implement the IExecutionPlanPreAndPostFilter interface if it wants to evaluate non-execution plan members first (to avoid retrieving the execution plan for queries that can be eliminated by something else such as I/O, time, etc) and then apply a second filter on something that is contained within SQL Server's execution plan.
But yes, you're right, better documentation and more code samples are needed and are under way...
|
|
0
• permalink
|