Rick Welykochy a écrit :
> Henri-Damien LAURENT wrote:
>
>> But paul also spoke about zebra queries and they are not logged nor
>> saved into the database at the moment
>> which could be good for storing user queries history but is an other
>> point.
>
> Which could perhaps be considered an audit
hdl: no, the variables there were just an extension of Paul's original
syntax, imagined to be easily parseable.
Jesse: YAML sounds good to me, too. The only reason for suggesting xml or
xml-ish
format is we already use XML::Simple, so have an easy way to parse without
additional modules.
rick
Henri-Damien LAURENT wrote:
> But paul also spoke about zebra queries and they are not logged nor
> saved into the database at the moment
> which could be good for storing user queries history but is an other point.
Which could perhaps be considered an audit function. Has consideration been
give
Rick Welykochy a écrit :
> Paul POULAIN wrote
>> So I think queries should be logged.
>>
>> + that would give us some datas to analyse the queries done by users. We
>> just need the analysis too to be written ;-)
>>
>
> Not in a production environment. You are imposing your own debugging
> re
On Fri, Aug 29, 2008 at 11:32 AM, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> I agree, except for query logging. It has been proven many times to me
> that it's usefull : the library tells you "I search this, and got no
> results, there's a bug in koha".
> You look in the logs, and see that the searc
Jesse Weaver wrote:
> OK then. How about YAML?
Who is going to write this stuff? Application programmers, DBAs,
sys admins or librarians?
Each different skillset has a different kind of solution.
cheers
rickw
--
Rick Welykochy
NOTE: This is an RFC patch. I don't expect it to be directly applied
to your system, and please don't apply it to the main Koha repository!
Here is an example of how we can use Log4perl to extend (and hopefully
improve) our current logging methods. I'm hopeful that this does a
few things for us:
On Fri, Aug 29, 2008 at 3:18 PM, Rick Welykochy <[EMAIL PROTECTED]> wrote:
> Henri-Damien LAURENT wrote:
>
> >>
> >> Patrons nearing expiry
> >> Members
> >> Patrons with expiry dates in the next n
> days
> >> SELECT cardnumber, surname, firstname, branchcode,
> >> categories.description,
Henri-Damien LAURENT wrote:
>>
>> Patrons nearing expiry
>> Members
>> Patrons with expiry dates in the next n days
>> SELECT cardnumber, surname, firstname, branchcode,
>> categories.description, dateexpiry from borrowers
>> LEFT JOIN categories on
>> borrowers.categorycode=c
Paul POULAIN wrote:
> So I think queries should be logged.
>
> + that would give us some datas to analyse the queries done by users. We
> just need the analysis too to be written ;-)
Not in a production environment. You are imposing your own debugging
requirements on all users of a production s
Ryan Higgins a écrit :
>
> I prefer an xml schema that would allow export and import of guided
> reports
> with included db revision to test against :
>
>
> Patrons nearing expiry
> Members
> Patrons with expiry dates in the next n days
> SELECT cardnumber, surname, firstname, branchcode,
"Problem
The ability is needed to search for patrons on many different fields, including
email address, street address, phone number, etc. Using additional patron
attributes is not a viable solution as it would require a tremendous amount of
duplicate data on all fields that would need to be sea
I prefer an xml schema that would allow export and import of guided reports
with included db revision to test against :
Patrons nearing expiry
Members
Patrons with expiry dates in the next n days
SELECT cardnumber, surname, firstname, branchcode,
categories.description, dateexpiry from bo
Hi,
On Fri, Aug 29, 2008 at 11:32 AM, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> I agree, except for query logging. It has been proven many times to me
> that it's usefull : the library tells you "I search this, and got no
> results, there's a bug in koha".
> You look in the logs, and see that the
Rick Welykochy a écrit :
> Galen Charlton wrote:
>
>> Ideally, all Perl scripts and modules should have warnings enabled by
>> the time 3.2 is released.
>
> 1000 applauds. Furthermore, demand that the error_log is *empty*
> during normal use, i.e. a non debug environment.
I agree, except for quer
Henri-Damien LAURENT a écrit :
> It also could be part of the SQL files we could propose at install time,
> imho, click to select a report, with a txt file to describe it, maybe
> with a sample.
That one should be pretty easy. we have the structure for this, to
populate canned reports as we popu
16 matches
Mail list logo
