Re: represent the object in the logs

2017-04-12 Thread Rafael Weingärtner
I disagree with the idea of logging anything (increasing logging just by quantity), like that fallacy of big data era of more and more. If you want to find a needle in a haystack, you do not add more hay, you remove them. However, increasing the quality of data being logged, I am totally in favor!

Re: represent the object in the logs

2017-04-12 Thread Rene Moser
Hi Rafael On 04/12/2017 08:27 PM, Rafael Weingärtner wrote: > Well, I think the missing point to understand why we have these different > situations is the understanding of the developer’s mind. It is so diverse > and unique from people to people, and because we do not have a policy on > that, eac

Re: represent the object in the logs

2017-04-12 Thread Rafael Weingärtner
Well, I think the missing point to understand why we have these different situations is the understanding of the developer’s mind. It is so diverse and unique from people to people, and because we do not have a policy on that, each developer is doing the best they know and think. For instance, at

represent the object in the logs

2017-04-12 Thread Rene Moser
Hi In logs we see all kind variations how an object is printed to the users. E.g. for VMs we have seen, the DB ID, UUID, internal name, name etc. in different debug log messages. And this makes debugging harder than it should. I wondered, why don't we just use the "toString()" in VO classes. E.g