[Koha-bugs] [Bug 16579] Use separate memcached namespace for caching koha-conf.xml

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Wed Aug 3 15:58:04 CEST 2016


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16579

--- Comment #26 from Jonathan Druart <jonathan.druart at bugs.koha-community.org> ---
Hi Jacek and Srdjan!
Thanks for taking a look and sorry for the delay to get back to you.

(In reply to Jacek Ablewicz from comment #24)
> (In reply to Jonathan Druart from comment #21)
> > Could someone take a look at these patches?
> 
> Overall they look (mostly) fine to me, or at least a move in the right
> direction[s]. They are a bit hard to digest though, lots of collateral fixes
> included - if some of them could be (?) moved to the separate reports,
> signing off and Q&A will probably have a much better chance to occur in
> foreseeable future ;).

That's why I have prefixed the commit messages with Bug XXXXX_1|2|3.
Patches with "Bug XXXXX_1" should go on their own bug report, same with _2 and
_3.
I plan to move them, but I wanted to know if the different changes were
appreciated before splitting them.

> Not sure if I fully understand a concept of namespaces / sub-namespaces
> introduced with this patch set (and what are they needed for exactly,
> especially in such particular form). E.g. L1 storage hash still remains a
> shared singleton (sort of) - moving L1 storage to the cache objects instead
> (and ideally tying those objects to the Koha contexts in 1:1 relationship)
> seems to be much less headache-prone long term solution IMO.

Yes indeed, it was the easy and lazy approach. My first idea was to manage it
from Koha::Caches which makes more sense, but it was not so easy.
I'd be happy to improve that if you have a good idea on how to do it.

(In reply to Srdjan Jankovic from comment #25)
> (In reply to Jacek Ablewicz from comment #24)
> > By the look of it, in regards of cache architectural changes, there will be
> > some overlap with Bug 15562, which in parts does somehow similar things with
> > the cache (and a lot of other interesting things as well, but it's huge and
> > I don't really understand ~half of it). Are there any chances of coordinated
> > effort of some sort, so they both don't clash too badly with each other?
> 
> That's terrible. Next time I rebase I'll try to make it more readable.
> Apologies.
> 
> Changes presented here are almost identical to the changes 15562, except
> that they are a bit better:
> * I fell short of introducing Koha::Config which I should have (I chickened
> out)
> * Koha::Caches - maybe we need to mandate the namespace when instantiating
> Koha::Cache in order for this to be more robust?

Does that mean you would agree to let these patches make his own way then
rebase yours? :)

> One thing that might be worth thinking about is that the very same problem
> exists with the database connections. So maybe some über class,
> Koha::Storage or something that would have a slot for everything we use, and
> then Koha::Storages collection keyed by the namespace?

I think we are dealing pretty well with our cache improvements: we improve it a
lot without breaking anything (so far!), using small steps.
So I'd suggest to continue like that and keep in mind these Koha::Storage[s]
classes

What's next? :)

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list