Thanks your feedback until now!
I tend to agree more with Mason here. If Paul adjusts his patch to meet QA,
let's move forward with that patch. Adding the REVERT logic would make it even
better later on.
To get the discussion further, I think we still need two answers:
1) Should we add the di
On 2012-06-16, at 6:51 AM, Ian Walls wrote:
> Just bringing this back to original intent: it's hard for developers and
> testers to work with patches that have DB revs, so we want to fix that.
> Basically, that means being able to easily tell what changes have been made
> to the DB beyond th
Dear Koha Kommunitarians,
I'm harvesting news for the June newsletter. Please send me by the
25th anything you think your fellow community members might like to
know about. I'm particularly interested in accounts of happenings at KohaCon12.
"News" can be as short as a sentence or as long as a pap
Just bringing this back to original intent: it's hard for developers and
testers to work with patches that have DB revs, so we want to fix that.
Basically, that means being able to easily tell what changes have been made
to the DB beyond the natural Koha progression.
The problem with the code we
> This should never have been in the database. Also, there is a 1-1
> relationship between almost all the language tables. We should just have
> sort of configuration file with that information (maybe in YAML?). Also,
> using just one type of language code might be nice.
>
> * XSLT parsing. That's
This might be this bug:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8243
Nicole
On Fri, Jun 15, 2012 at 12:19 AM, Mason James wrote:
>
> On 2012-06-15, at 1:07 PM, Bernardo Gonzalez Kriegel wrote:
>
>> Hi,
>> we noted a strange behavior: if check out an item and immediately check in
Op 13-06-12 15:39, Jared Camins-Esakov schreef:
> Development mode: Currently, you rely on $ENV{DEBUG} from koha-httpd
> file. I would turn this into a systempref. It is easier for
> developers to toggle it (compared to restarting httpd service).
>
> It's easier, but also a lot more da
Paul,
On Fri, Jun 15, 2012 at 5:42 AM, Paul Poulain wrote:
> Le 15/06/2012 11:32, Dobrica Pavlinusic a écrit :
> > I look at memoize as a easy way to find our which parts of our data
> > model should be cached. Once we find contended places, we can remove
> > memoize and implement proper compute
Am 15.06.12 11:32, schrieb Dobrica Pavlinusic:
[...]
>> P.S. If we need to replace the SQL query cache with a local cache, doesn't
>> this mean we're doing it wrong?
>
> Sure, but it's low-hanging fruit, and this is currently a huge
> show-stopper if you want to have MySQL on another machine sin
Le 15/06/2012 11:32, Dobrica Pavlinusic a écrit :
> I look at memoize as a easy way to find our which parts of our data
> model should be cached. Once we find contended places, we can remove
> memoize and implement proper compute for that part of code.
quick answer (I'll answer more completely la
On Thu, Jun 14, 2012 at 03:23:59PM -0400, Jared Camins-Esakov wrote:
> > - very nice syntax:
> >
> > my $customer2 = $cache->compute($name2, "10 minutes", sub {
> >get_customer_from_db($name2)
> > });
> >
> > Which I would prefer to our existing Koha::Cache API. It would also save
> > us qu
11 matches
Mail list logo
