Hi,
>From my brief reading of the Qvarn documentation it seems like a solid piece of
well-thought out enginerring.
However, to replace Koha's database interaction with Qvarn would be an enourmus
task, as well as increasing the complexity of the deployment manyfold with
additional
layers,
Hi Lars,
Since 2010, a lot of things have changed and are currently going on.
We are moving our code from the legacy C4 to the new Koha namespace.
It might interest you to know that as I am currently moving the patron code
(see bug 16846). I personally don't thing it's conceivable to implement
Hi,
>From my brief reading of the Qvarn documentation it seems like a solid piece of
well-thought out enginerring.
However, to replace Koha's database interaction with Qvarn would be an enourmus
task, as well as increasing the complexity of the deployment manyfold with
additional
layers,
Hi All
With the move to DBIx::Class we do gain some db independence. But we don't
improve privacy much. This is where Qvarn would come in, if I am understanding
correctly, the back end some of our stuff would become Qvarn, if we implement
it correctly it would be handled by the Object level
Hi Lars,
We are moving - slowly - away from SQL all over the place with DBIx and
Koha::Object[s].
At the same time moving code from C4 to these Koha objects.
This is a huge operation.
Another ongoing project is the extension of the RESTful API (using Mojolicious
and Swagger).
So, things are
LARS!
I have not been very involved in Koha work lately but remain a faithful
lurker.
The first thing that comes to mind which might be an obstacle to adopting
something like this is the library of SQL reports. I think this is a
collection of value that the community has created and maintains
Hi, Koha developers,
some of you may remember me from the Debian packaging of Koha I made
in 2010 for Catalyst IT. I've never looked much at the actual code
base of Koha, but one thing that even a quick grep reveals is that SQL
code is sprinkled all over the code base. To me, this indicates that
