You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Evgeny Ryabitskiy (JIRA)" <ji...@apache.org> on 2010/07/14 11:04:49 UTC

[jira] Created: (CAY-1464) Improve QueryLogger to log more information

Improve QueryLogger to log more information
-------------------------------------------

                 Key: CAY-1464
                 URL: https://issues.apache.org/jira/browse/CAY-1464
             Project: Cayenne
          Issue Type: Improvement
          Components: Core Library
    Affects Versions: 3.1M1
            Reporter: Evgeny Ryabitskiy
            Assignee: Evgeny Ryabitskiy
             Fix For: 3.1M1


Since I have to support lot's of applications using Cayenne and usually Cayenne logs is only information I have about some bugs, I wish to have more information in that logs.

I think it will be nice to have:

1) Information of query that was executed (e.g. name of NamedQuery). To find right query in thousands...
2) Result of Select query.
3) As much information as it could be collected while logging errors.Like:  What query? Params? What Query String was build? Connection pool State? Driver version? Cayenne version? Better more than less.... 

Last one can be very useful since on production I have only ERROR logging level. And sometimes it is not possible to enable INFO level to find out what happen. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CAY-1464) Improve QueryLogger to log more information

Posted by "Andrus Adamchik (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CAY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888286#action_12888286 ] 

Andrus Adamchik commented on CAY-1464:
--------------------------------------

Somewhat related is CAY-1173, which will likely be revisited in 3.1 as DI container gives us more flexibility to implement it. The idea is to provide events at certain points of query execution, and then support various listeners. Some of those may aggregate all events during a query cycle and give full diagnostics. The good thing about this design is that by default it won't incur much performance overhead, but users who need to trace low level details, may implement their own listeners with more complex logic. E.g. the original motivation for CAY-1173 was to implement JMX monitoring of Cayenne stacks.

> Improve QueryLogger to log more information
> -------------------------------------------
>
>                 Key: CAY-1464
>                 URL: https://issues.apache.org/jira/browse/CAY-1464
>             Project: Cayenne
>          Issue Type: Improvement
>          Components: Core Library
>    Affects Versions: 3.1M1
>            Reporter: Evgeny Ryabitskiy
>            Assignee: Evgeny Ryabitskiy
>             Fix For: 3.1M1
>
>
> Since I have to support lot's of applications using Cayenne and usually Cayenne logs is only information I have about some bugs, I wish to have more information in that logs.
> I think it will be nice to have:
> 1) Information of query that was executed (e.g. name of NamedQuery). To find right query in thousands...
> 2) Result of Select query.
> 3) As much information as it could be collected while logging errors.Like:  What query? Params? What Query String was build? Connection pool State? Driver version? Cayenne version? Better more than less.... 
> Last one can be very useful since on production I have only ERROR logging level. And sometimes it is not possible to enable INFO level to find out what happen. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (CAY-1464) Improve QueryLogger to log more information

Posted by "Evgeny Ryabitskiy (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CAY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Evgeny Ryabitskiy updated CAY-1464:
-----------------------------------

    Attachment: CAY-1464.patch

Patch to Default Cayenne logger.

> Improve QueryLogger to log more information
> -------------------------------------------
>
>                 Key: CAY-1464
>                 URL: https://issues.apache.org/jira/browse/CAY-1464
>             Project: Cayenne
>          Issue Type: Improvement
>          Components: Core Library
>    Affects Versions: 3.1M1
>            Reporter: Evgeny Ryabitskiy
>            Assignee: Evgeny Ryabitskiy
>             Fix For: 3.1M1
>
>         Attachments: CAY-1464.patch
>
>
> Since I have to support lot's of applications using Cayenne and usually Cayenne logs is only information I have about some bugs, I wish to have more information in that logs.
> I think it will be nice to have:
> 1) Information of query that was executed (e.g. name of NamedQuery). To find right query in thousands...
> 2) Result of Select query.
> 3) As much information as it could be collected while logging errors.Like:  What query? Params? What Query String was build? Connection pool State? Driver version? Cayenne version? Better more than less.... 
> Last one can be very useful since on production I have only ERROR logging level. And sometimes it is not possible to enable INFO level to find out what happen. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Re: [jira] Commented: (CAY-1464) Improve QueryLogger to log more information

Posted by Andrus Adamchik <an...@objectstyle.org>.
On Aug 2, 2010, at 12:30 PM, Evgeny Ryabitskiy wrote:

> * Looks like you patch will log all fetched objects? If this is the
> * case, it is definitely a bad idea. There can be *lots* of them.
>
> Yes... I would suggest to separate this into several levels INFO and
> DEBUG, DEBUG is for logging fetched objects.
> If it's not applicable we could move it in another Logger  
> implementation.

Yes please, let's make it a separate logger.


> * What is the benefit of passing start time instead of time delta in
> * the logger? IMO the "old" API was cleaner, separating time  
> measurement
> * from logging.
>
> Benefit is that we shouldn't do startTime - endTime if Logging is
> disabled. -2 Operations (getCurrTime for endTime and operator "-"), so
> low CPU is used.
> I know it's minor optimization... but still... :) Unfortunately API
> become little bit less clear.

Yep. In a case of negligible performance optimization vs. clean API I  
always vote for the later. That's what ORM is about :-)


> * BTW, my other idea about was that we can define a very simple logger
> API, while "advanced" loggers would take extra
> * information about the current operation from the injectable
> environment objects (or maybe from thread-bound Transaction).
>
> Maybe you are right and I could resolve Connection from thread-bound
> Transaction.. but it's to much binded on this Transaction object...

What do you mean "too much"?

Andrus


Re: [jira] Commented: (CAY-1464) Improve QueryLogger to log more information

Posted by Evgeny Ryabitskiy <ev...@gmail.com>.
Hi!


* Looks like you patch will log all fetched objects? If this is the
* case, it is definitely a bad idea. There can be *lots* of them.

Yes... I would suggest to separate this into several levels INFO and
DEBUG, DEBUG is for logging fetched objects.
If it's not applicable we could move it in another Logger implementation.


* What is the benefit of passing start time instead of time delta in
* the logger? IMO the "old" API was cleaner, separating time measurement
* from logging.

Benefit is that we shouldn't do startTime - endTime if Logging is
disabled. -2 Operations (getCurrTime for endTime and operator "-"), so
low CPU is used.
I know it's minor optimization... but still... :) Unfortunately API
become little bit less clear.


* BTW, my other idea about was that we can define a very simple logger
API, while "advanced" loggers would take extra
* information about the current operation from the injectable
environment objects (or maybe from thread-bound Transaction).

Maybe you are right and I could resolve Connection from thread-bound
Transaction.. but it's to much binded on this Transaction object...


Evgeny.



2010/8/2 Andrus Adamchik <an...@objectstyle.org>:
> BTW, my other idea about was that we can define a very simple logger API,
> while "advanced" loggers would take extra information about the current
> operation from the injectable environment objects (or maybe from
> thread-bound Transaction).
>
> Andrus
>
> On Aug 2, 2010, at 11:50 AM, Andrus Adamchik wrote:
>
>> Hi Evgeny,
>>
>> On Aug 1, 2010, at 6:13 PM, Evgeny Ryabitskiy (JIRA) wrote:
>>>
>>> Evgeny Ryabitskiy commented on CAY-1464:
>>> ----------------------------------------
>>>
>>> + 1 for flexibility at this level.
>>>
>>> Now we should think about what to path to this events, I mean some
>>> interface for it.
>>>
>>> And I am still think that default Cayenne logger can be Improved without
>>> "incur much performance overhead", to provide nice logging "out of box".
>>> That was patch about.
>>
>>
>> Just took a brief look at the patch... I have some minor notes about error
>> messages and such, but here are a few things that I have doubts about:
>>
>> * Looks like you patch will log all fetched objects? If this is the case,
>> it is definitely a bad idea. There can be *lots* of them.
>> * What is the benefit of passing start time instead of time delta in the
>> logger? IMO the "old" API was cleaner, separating time measurement from
>> logging.
>>
>>> + There could be several build-in loggers that could be "turned on" just
>>> by one simple option.
>>>
>>> 1) Default Logger
>>> 2) Formatted logger (move format issues here).
>>> 3) Some supper logger that could provide lot's of output.
>>
>> Yep. DI container is already a reality, so switching to a DI-based logger
>> should be fairly starightforward (we'll need to figure out injection into
>> lower level objects underneath DataDomain). This is on my TODO list. If
>> somebody decides to do it before I get to it, please open a Jira and let me
>> know.
>>
>> Andrus
>>
>>
>
>

Re: [jira] Commented: (CAY-1464) Improve QueryLogger to log more information

Posted by Andrus Adamchik <an...@objectstyle.org>.
BTW, my other idea about was that we can define a very simple logger  
API, while "advanced" loggers would take extra information about the  
current operation from the injectable environment objects (or maybe  
from thread-bound Transaction).

Andrus

On Aug 2, 2010, at 11:50 AM, Andrus Adamchik wrote:

> Hi Evgeny,
>
> On Aug 1, 2010, at 6:13 PM, Evgeny Ryabitskiy (JIRA) wrote:
>> Evgeny Ryabitskiy commented on CAY-1464:
>> ----------------------------------------
>>
>> + 1 for flexibility at this level.
>>
>> Now we should think about what to path to this events, I mean some  
>> interface for it.
>>
>> And I am still think that default Cayenne logger can be Improved  
>> without "incur much performance overhead", to provide nice logging  
>> "out of box". That was patch about.
>
>
> Just took a brief look at the patch... I have some minor notes about  
> error messages and such, but here are a few things that I have  
> doubts about:
>
> * Looks like you patch will log all fetched objects? If this is the  
> case, it is definitely a bad idea. There can be *lots* of them.
> * What is the benefit of passing start time instead of time delta in  
> the logger? IMO the "old" API was cleaner, separating time  
> measurement from logging.
>
>> + There could be several build-in loggers that could be "turned on"  
>> just by one simple option.
>>
>> 1) Default Logger
>> 2) Formatted logger (move format issues here).
>> 3) Some supper logger that could provide lot's of output.
>
> Yep. DI container is already a reality, so switching to a DI-based  
> logger should be fairly starightforward (we'll need to figure out  
> injection into lower level objects underneath DataDomain). This is  
> on my TODO list. If somebody decides to do it before I get to it,  
> please open a Jira and let me know.
>
> Andrus
>
>


Re: [jira] Commented: (CAY-1464) Improve QueryLogger to log more information

Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Evgeny,

On Aug 1, 2010, at 6:13 PM, Evgeny Ryabitskiy (JIRA) wrote:
> Evgeny Ryabitskiy commented on CAY-1464:
> ----------------------------------------
>
> + 1 for flexibility at this level.
>
> Now we should think about what to path to this events, I mean some  
> interface for it.
>
> And I am still think that default Cayenne logger can be Improved  
> without "incur much performance overhead", to provide nice logging  
> "out of box". That was patch about.


Just took a brief look at the patch... I have some minor notes about  
error messages and such, but here are a few things that I have doubts  
about:

* Looks like you patch will log all fetched objects? If this is the  
case, it is definitely a bad idea. There can be *lots* of them.
* What is the benefit of passing start time instead of time delta in  
the logger? IMO the "old" API was cleaner, separating time measurement  
from logging.

> + There could be several build-in loggers that could be "turned on"  
> just by one simple option.
>
> 1) Default Logger
> 2) Formatted logger (move format issues here).
> 3) Some supper logger that could provide lot's of output.

Yep. DI container is already a reality, so switching to a DI-based  
logger should be fairly starightforward (we'll need to figure out  
injection into lower level objects underneath DataDomain). This is on  
my TODO list. If somebody decides to do it before I get to it, please  
open a Jira and let me know.

Andrus


[jira] Commented: (CAY-1464) Improve QueryLogger to log more information

Posted by "Evgeny Ryabitskiy (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CAY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894386#action_12894386 ] 

Evgeny Ryabitskiy commented on CAY-1464:
----------------------------------------

+ 1 for flexibility at this level.

Now we should think about what to path to this events, I mean some interface for it.

And I am still think that default Cayenne logger can be Improved without "incur much performance overhead", to provide nice logging "out of box". That was patch about.

+ There could be several build-in loggers that could be "turned on" just by one simple option.

1) Default Logger
2) Formatted logger (move format issues here).
3) Some supper logger that could provide lot's of output.


> Improve QueryLogger to log more information
> -------------------------------------------
>
>                 Key: CAY-1464
>                 URL: https://issues.apache.org/jira/browse/CAY-1464
>             Project: Cayenne
>          Issue Type: Improvement
>          Components: Core Library
>    Affects Versions: 3.1M1
>            Reporter: Evgeny Ryabitskiy
>            Assignee: Evgeny Ryabitskiy
>             Fix For: 3.1M1
>
>         Attachments: CAY-1464.patch
>
>
> Since I have to support lot's of applications using Cayenne and usually Cayenne logs is only information I have about some bugs, I wish to have more information in that logs.
> I think it will be nice to have:
> 1) Information of query that was executed (e.g. name of NamedQuery). To find right query in thousands...
> 2) Result of Select query.
> 3) As much information as it could be collected while logging errors.Like:  What query? Params? What Query String was build? Connection pool State? Driver version? Cayenne version? Better more than less.... 
> Last one can be very useful since on production I have only ERROR logging level. And sometimes it is not possible to enable INFO level to find out what happen. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.