Generating a report from an ugly log file
Srijayanth Sridhar
Hello,
I have the following problem.
There exists a really ugly debug log file which has mysql query statements.
Looking through the log makes it hard to understand esp while providing
reports to bosses/mgrs etc. so I have decided to make it more "English". I
have over 40 queries, each that can be called in different ways, for
instance:
1) select foo1, foo2 from foo where foo1=... etc
2) select foo1 from foo where foo1= etc
The basic parsing would be /select(.*)\s+from\s+(.*)(?:\s+where\s+(.*)$)/ #
its a bit more advanced, but its solved and hence not a problem
#captures[1] will be the table name
1) Each table/view is its own class with a to_english method that does the
translation
2) An abstract class that parses a line from the log file, extracts the
table or view (in this case foo) from the match and generates an object
using eval "#{table.capitalize}.new captures"
3) The to_english method generates an English representation of the object
based on logic that uses information from the various captures passed in.
The idea is to have a list of objects that I iterate over and do a
#to_english
My questions are:
1) Should I organize this differently and run away from eval?
2) Since there are over 40 odd classes, is there a better way to require
them other than:
Dir.glob("qry*").each { |r| require r }
Thank you,
Jayanth
Mark Thomas
> [Note: parts of this message were removed to make it a legal post.]
>
> Hello,
>
> I have the following problem.
>
> There exists a really ugly debug log file which has mysql query statements.
> Looking through the log makes it hard to understand esp while providing
> reports to bosses/mgrs etc. so I have decided to make it more "English". I
> have over 40 queries, each that can be called in different ways, for
> instance:
>
> 1) select foo1, foo2 from foo where foo1=... etc
> 2) select foo1 from foo where foo1= etc
>
> The basic parsing would be /select(.*)\s+from\s+(.*)(?:\s+where\s+(.*)$)/ #
> its a bit more advanced, but its solved and hence not a problem
>
> #captures[1] will be the table name
>
> 1) Each table/view is its own class with a to_english method that does the
> translation
Do you really need this? It may be overkill if the only thing you will
do in each of these classes is a to_english method. You could perhaps
use a singleton class that contains all the translations.
> 2) An abstract class that parses a line from the log file, extracts the
> table or view (in this case foo) from the match and generates an object
> using eval "#{table.capitalize}.new captures"
To avoid eval, use
Kernel.const_get(table.capitalize).send(:to_english)
where to_english is a class method.
Srijayanth Sridhar
Thanks.
Unfortunately, I plan to do more than just to_english. The logs have
information that is also dependent on the ordering of the mysql statements
themselves, so I want to be able to map queries based on certain conditions
etc, so no running away from it really, but the Kernel#const_get#send is a
nice option.
Jayanth