[jira] Commented: (DERBY-549) remove Diagnostic framework from Derby

["Tomohito Nakayama (JIRA)" <de...@db.apache.org>]

    [ http://issues.apache.org/jira/browse/DERBY-549?page=comments#action_12320776 ] 

Tomohito Nakayama commented on DERBY-549:
-----------------------------------------

My current vote is + 0.5 .

I could agree that functionality that Diagnostic framework provide exists near domain of debugger and this framework should be removed .
Making program as simple as possible is very fascinating .

However , there would be room for  Diagnostic framework to serve more rich information than just instance variables of Diagnosticable object , which is impossible just using debugger .

> remove Diagnostic framework from Derby
> --------------------------------------
>
>          Key: DERBY-549
>          URL: http://issues.apache.org/jira/browse/DERBY-549
>      Project: Derby
>         Type: Task
>   Components: Services
>     Reporter: Tomohito Nakayama

>
> There are question wheter Diagnostic framework should be exists in derby, because the functionality it is trying to provide is really the domain ofa Java debugger.
> This issue was invoked by next mail posted by Dan.
> http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/7737

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (DERBY-549) remove Diagnostic framework from Derby

[Mike Matrigali <mi...@sbcglobal.net>]

I like the diagnostic stuff, though it never was taken to
where it was going.  The idea originally was a set of classes
which could be packaged up in a separate jar and added
to the end of your class path which would
seemlessly integrate with a delivered jar to provide more
diagnostic information then was reasonable to include in
the delivered product.  Thus most users did not have to pay
the increased foot print and possible performance overhead
of the diagnostic information.

The idea was to provide queries/tools so that one could tell
a remote customer:  add this jar to your class path and run
this query and send us the results that got printed to your
log file.

The store uses the diagnostic classes to do things like dump
the entire structure of a table or a page in a formatted way,
I don't think this functionality is done well by a debugger.
This can of course be done in a different way, but is the
current way one can debug a corrupt page or table structure.

Tomohito Nakayama (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/DERBY-549?page=comments#action_12320776 ] 
> 
> Tomohito Nakayama commented on DERBY-549:
> -----------------------------------------
> 
> My current vote is + 0.5 .
> 
> I could agree that functionality that Diagnostic framework provide exists near domain of debugger and this framework should be removed .
> Making program as simple as possible is very fascinating .
> 
> However , there would be room for  Diagnostic framework to serve more rich information than just instance variables of Diagnosticable object , which is impossible just using debugger .
> 
> 
>>remove Diagnostic framework from Derby
>>--------------------------------------
>>
>>         Key: DERBY-549
>>         URL: http://issues.apache.org/jira/browse/DERBY-549
>>     Project: Derby
>>        Type: Task
>>  Components: Services
>>    Reporter: Tomohito Nakayama
> 
> 
>>There are question wheter Diagnostic framework should be exists in derby, because the functionality it is trying to provide is really the domain ofa Java debugger.
>>This issue was invoked by next mail posted by Dan.
>>http://permalink.gmane.org/gmane.comp.apache.db.derby.devel/7737
> 
>