gmane.education.libraries.koha.devel

Re: [DISCUSSION] Database schema & coding guidelines

Chris Nighswonger — 2012-05-25T16:30:02

I agree with Marc here. The best way is the correct way which is to cite
the "relative path" ie. table.column. Otherwise I'd prefer option 4 for the
reasons already stated by several.

Kind Regards,
Chris
_______________________________________________
Koha-devel mailing list
Koha-devel-yy2XUMoudrGBeeJdjao7tfCrwMbev77B< at >public.gmane.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [DISCUSSION] Database schema & coding guidelines

Marc Balmer — 2012-05-25T16:23:00

Am 25.05.12 18:00, schrieb Paul Poulain:

Technically, the name of a column does not matter much, since you can
always refer to it as <tablename>.<columnname> to make it unambigous.
In some databases that support schemas, like PostgreSQL, you can refer
to columns even as <schemaname>.<tablename>.<columnname>.


I contradict.  This results neither in complexity nor in mistakes.
Imagine two tables, A and B, which both have an id column, then a select
would probably look like the following:

select A.id as aid, B.id as bid from A, B, where ...

So it's not a problem.


These three examples are only a matter of taste whithout any advantages
or disadvantages.


Since the name of a columns is actually not of any importance, from a
technical/database view, why impose restrictions on how to use them?

Not the column name, but the table schema should indicate whether
something is a primary key or not.

That said, I can live with any of above naming schemes, but I would
prefer to not have a rule on this.

I'd prefer [

Re: [DISCUSSION] Database schema & coding guidelines

Ian Walls — 2012-05-25T16:15:59

I also favour "_id" in general... the underscore separates it out as an
identifier, and it's already this way in a large percentage of the database.

We need to be very careful, though, if we change any of the existing key
names, so that it not only doesn't break the Koha code, but also doesn't
break saved Reports.  The database update script must do a find/replace in
the saved_sql.savedsql field (and should also update
saved_sql.last_modified in the process).


-Ian

On Fri, May 25, 2012 at 12:04 PM, Jared Camins-Esakov <
jcamins-uxnXpNWeGHonjDBjJMeEydBPR1lH4CV8< at >public.gmane.org> wrote:

_______________________________________________
Koha-devel mailing list
Koha-devel-yy2XUMoudrGBeeJdjao7tfCrwMbev77B< at >public.gmane.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [DISCUSSION] Database schema & coding guidelines

Jared Camins-Esakov — 2012-05-25T16:04:18

Paul, et. al.,

On Fri, May 25, 2012 at 12:00 PM, Paul Poulain <paul.poulain-zkl4Dl7PsEhWk0Htik3J/w< at >public.gmane.org>wrote:


I favor this option. I think it's readable, unlike (2), and short, unlike
(6).

 5- xxxxnumber => number is quite long, and may result in very long

Regards,
Jared

[DISCUSSION] Database schema & coding guidelines

Paul Poulain — 2012-05-25T16:00:22

In the wiki page http://wiki.koha-community.org/wiki/DB_schema_bugs, an
insconsistency has been noticed:
primary keys column name can be: id (in authorised_values table), xxxid
(cityid), xxx_id (label_id), xxxId (limitId), xxxcode (branchcode),
xxxnumber (borrowernumber) => choose how to name PK and update schema
accordingly

The bug 7065 add a foreign key to the reserves table, so I think it's
time to clearly choose how we name primary keys.

The possible options are below, my opinion:

 1- id alone => will result in complexity & mistakes, this option must
be discarded
 2- xxxxid => short option, may result in hard readability.
 3- xxxxId => we haven't decided if we want UC in field names. I won't
discard this option, but does not favour it.
 4- xxx_id => _ still undecided in field names, I'm not sure it's much
better than the xxxid one
 5- xxxxnumber => number is quite long, and may result in very long
field names, which is not good. I does not like this option.

Let's start the discussion

Koha 3.6.5 released

Jared Camins-Esakov — 2012-05-25T14:12:26

The Koha release team is happy to announce the release of Koha 3.6.5

This is a stable release and contains bugfixes as well as updated
translations.

You can download it at

http://download.koha-community.org/

Go forth, download, and enjoy :)

RELEASE NOTES FOR KOHA 3.6.5
24 May 2012
========================================================================

Koha is the first free and open source software library automation package
(ILS). Development is sponsored by libraries of varying types and sizes,
volunteers, and support companies from around the world.
The website for the Koha project is

    http://koha-community.org/

Koha 3.6.5 can be downloaded from:

    http://download.koha-community.org/koha-3.06.05.tar.gz

Installation instructions can be found at:

    http://wiki.koha-community.org/wiki/Installation_Documentation

    OR in the INSTALL files that come in the tarball

Koha 3.6.5 is a bugfix/maintenance release.

Highlights of 3.6.5
======================

3916    critical    Batch Modify tool

Official Koha Newsletter: Volume 3, Issue 5: May 2012

Daniel Grobani — 2012-05-24T22:36:26

Official Koha Newsletter: Volume 3, Issue 5: May 2012

[Below is the text of the newsletter. For active links and a more
readable format, please visit
http://koha-community.org/koha-newsletter-volume-3-issue-5-may-2012]

Official Koha Newsletter (ISSN 2153-8328)
Volume 3, Issue 5: May 2012

Edited by Daniel Grobani, Koha Community Newsletter Editor.

Please submit news items to danielg.koha-Re5JQEeQqe9fmgfxC/sS/w< at >public.gmane.org

Table of Contents

    Koha Development
        Koha 3.8.1 Released
        Koha 3.6.5 Release Imminent
        Koha Statistics
        Database Schema Documentation Updated
    Koha Community
        New Koha Libraries
        Community Gossip
    Past Koha Events
        May General IRC Meeting
        New Zealand Koha User Group Day 2012
    Upcoming Koha Events
        June General IRC Meeting
        KohaCon12
        KohaCon13

Koha Development

Koha 3.8.1 Released
by Chris Cormack

The Koha release team is happy to announce the release of Koha 3.8.1.
This is a stable release

DateTime::Format::MySQL

Chris Nighswonger — 2012-05-24T13:50:33

Hi all,

The QOTD work recently committed to master adds DateTime::Format::MySQL as
a core dependency thereby extending DateTime objects to handle proper
formatting of datetime strings for MySQL.

While Koha::DateUtils will parse ISO formatted datetime strings, the POD
notes that the module is intended to be a temporary aid
to demystify DateTime foo while we are transitioning fully to DateTime:

"Koha has historically only used dates not datetimes and been content to
40
handle these as strings. It also has confused formatting with actual dates
41
this is a temporary module for wrappers to hide the complexity of
switch to DateTime"

There are similar DateTime::Format::<db> plugins for Pg, Oracle, and
friends which may be implemented in Koha as support for those db's is added.

Basically DateTime::Format::MySQL will parse a correctly MySQL formatted
datetime and return a DateTime object for your morphing pleasure.

It will also format a DateTime object and return a MySQL datetime string.

Read more here: http:

Re: Print page - Firefox, etc

Owen Leonard — 2012-05-23T00:32:15

I don't know if this is the best way, but the most basic way is
probably to grab the updated file from the git web interface:

http://git.koha-community.org/gitweb/

I navigated to the 3.6.4 branch and found the most recent version of
the file in question, the staff client print stylesheet:

http://git.koha-community.org/gitweb/?p=koha-small.git;a=blob_plain;f=koha-tmpl/intranet-tmpl/prog/en/css/print.css;hb=441b98cea41ed7d99354195b79d5b4f44b194913

If you replace your file with that one it should be the functional
equivalent of reverting that commit.

  -- Owen

Re: Print page - Firefox, etc

Paul — 2012-05-23T00:15:52

[snip]

Thanks - what's the best way on a *production* server to revert the patch 
and install the better fix?

I must admit to not fully understanding how git (or whatever is most 
appropriate) is setup, and after a look at bug 6291, there appear to be 
quite a few elements touched.  In my sandbox, I once tried (unsuccessfully) 
to have two parallel but different versions of Koha so do not really want 
to try that on the production box.

Best - Paul



---
Maritime heritage and history, preservation and conservation,
research and education through the written word and the arts.
<http://UltraMarine.ca>, <http://AandC.org> and <http://MarDoc.ca>

_______________________________________________
Koha-devel mailing list
Koha-devel-yy2XUMoudrGBeeJdjao7tfCrwMbev77B< at >public.gmane.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: KOCT pushed on contrib repo

Chris Cormack — 2012-05-22T21:11:58

Awesome! Thank you

Chris
_______________________________________________
Koha-devel mailing list
Koha-devel-yy2XUMoudrGBeeJdjao7tfCrwMbev77B< at >public.gmane.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

KOCT pushed on contrib repo

Paul Poulain — 2012-05-22T21:07:21

Hello,

I just pushed a few minuts ago a patch with KOCT on the contrib repository
(http://git.koha-community.org/gitweb/?p=contrib/global.git;a=summary)

Re: Print page - Firefox, etc

Owen Leonard — 2012-05-22T18:01:32

Probably, in that your description matches exactly the PDF attached to
the bug ;)

However, I can't reproduce the problem in master so this may already
have been fixed. Tested in Firefox 12, Chrome 19, Opera 11, and IE 9
on Windows 7.

Judging from the description and the timeline of Koha 3.6.1 I'm
guessing the bug is caused by my first fix for Bug 6291 which was
subsequently reverted in favor of a better fix.

  -- Owen

Print page - Firefox, etc

Paul — 2012-05-22T15:49:56

Our cataloguers are having a local problem that I was unaware of. This is 
probably Koha bug 7199 which appears to be a tad inactive; I'd be happy to 
assist, but have no knowledge whatsoever of how browsers render 
CSS|templates for printing.

Trying to "print page" after a staff screen listing such as 
<http://koha-admin/cgi-bin/koha/catalogue/search.pl?q=lambert%2C+andrew> 
(the page itself is perfect) gives an oddball output with the "Results" and 
"Location" columns squeezed down to very narrow columns on the right hand 
side of the page. The "check box" column (normally very narrow) expands to 
well over 50% of page width.

This happens (for us at least) in Firefox (v. 12.0), Chrome (build 16.0), 
Safari (5.1) and MSIE (6.0 - we don't have anything more recent in our Win 
machine.)

A quick review of "equivalent" OPAC search pages (rather than staff-admin) 
shows no problems.

Koha 3.06.01.000, on Linux 2.6.38, Perl 5.010001, Apache 2.2.17, mysql Ver 
14.14 Distrib 5.1.54, for debian-linux-gnu

Thanks

Re: Proposed QA Enhancements

Ian Walls — 2012-05-22T15:44:23

For my part, I tend to review patches textual to see if they make sense as
a changeset.  If I cannot tell from reading what this patch does, I'll
either apply and test, or ask for clarification.  Generally, both of those
actions take more effort than reading on Bugzilla, and thus take longer.

I agree that it would be preferable to have the actual QA signoff on the
patch itself when it gets through QA, so that our git signoff stats are
more accurate.  That does add the additional overhead of pulling down and
applying each patch, then amending the commit and firing back up to BZ...
not complicated, but additional steps.  Hence why I haven't been doing it
reliably.

Any QA rules we can put into scripts to automatically check, I'm all for,
as that can relieve some of the more tedious work of checking spacing and
variable name declarations, and let QA look more in-depth about the patch's
implementation.  I know we've got a few such tests... anyone who is willing
to write more goes in my Nice Person book.

My new

Re: Proposed QA Enhancements

Marcel de Rooy — 2012-05-22T15:02:31

Just a quick response on first glance: The numbers in this discussion are imo far from accurate. As for me, I mostly QA without signing off, just to spare time. In most cases I did apply and test (at least some functionality, in other cases much more). I would not recommend doing QA in Bugzilla only, perhaps with the exception of very small things. 
Adding the rule that QA must do an additional signoff too will put more work (better testing etc.) on the QA team, and will result in more delay. If a QA member does not trust a patch, why not ask for a second signoff (older idea..)? 

________________________________________
Van: koha-devel-bounces-yy2XUMoudrGBeeJdjao7tfCrwMbev77B< at >public.gmane.org [koha-devel-bounces< at >lists.koha-community.org] namens Chris Cormack [chrisc-6STWZtX7tXAqAMOr+u8IRA< at >public.gmane.org]
Verzonden: dinsdag 22 mei 2012 10:51
To: Paul Poulain
Cc: koha-devel-yy2XUMoudrGBeeJdjao7tfCrwMbev77B< at >public.gmane.org
Onderwerp: Re: [Koha-devel] Proposed QA Enhancements

* Paul Poulain (paul.poulain-zk

Multi-Lingual SQL & User Defined Parameters

Massoud Alshareef — 2012-05-16T06:03:11

Hello,

I have asked a question about two years ago about when we can have Koha
support of Multi-Lingual SQL files (used for marc21/Auth fields description
in the Staff client) and Multi-Lingual users defined parameters (used for
describing items/ libraries & groups/ locations/ patrons categories/ etc),
and the answer from Koha development then was that it is
under consideration but not in the development pipelines yet, as it will
require some re-structuring in Koha system databases and controls. That
means, Koha will remain a single language in these areas.

With Koha 3.6 release, I noticed the inclusion of "Spanish translation for
SQL files" in the INTERNATIONALIZATION enhancement section. Does this mean
that Spanish Koha, or any non-English Koha, now has both Spanish and
English SQL files, where Koha users can switch between more than one
language when, for instance, editing marc records in the staff client ?

Koha Preferences description used to be in SQL files, which means a single
language prefers, and

Re: Proposed QA Enhancements

Chris Cormack — 2012-05-22T08:51:15

That's what Chris N was asking for, that a sign off is added when the
patch is tested, it must have been applied and tested, so why not sign
off and attach it back on the bug at the same time as changing the bug
status.

I'm not sure we want to get into a who does more for Koha contest, nor
do I think that was the point of this email.

I do think there are too many patches missing getting 2 independent
sign offs, and that is what we need to fix.

Chris

Re: Proposed QA Enhancements

Paul Poulain — 2012-05-22T08:40:22

Le 21/05/2012 19:38, Chris Nighswonger a écrit :
Something I made during the 3.8 release was to add many things to the
coding guidelines. My preference goes to QA rules that are clearly
defined and explained. That will help QAing a lot, and "anyone" with a
good Koha experience, and some time to dedicate should/could do it.

I agree that we *must* have a functional AND a technical review of every
patch, the 2 steps are different.

Most QA is done in bugzilla only: when a patch is QAed, it's not
signed-off & git bz attach most of the time.
(that's also why your numbers below are meaningless : Ian has not made
only 25 QA or joubu 5 ! OTOH, when I, as RM, push a patch, I always add
my signature, that can be as RM or QA)

As I just wrote, I don't do the majority of QA, (even if I agree I do a lot)

As I've said previously, as RM, I dedicate more than half of my time to
this task.
I think that we could have someone dedicated full time to QA and someone
dedicated full time to sign-off. And until we won't... we wil

Re: Koha 3.8.1 released

Chris Nighswonger — 2012-05-21T22:27:32

Huzza!

On Mon, May 21, 2012 at 5:32 PM, Chris Cormack <chris-BI0SDMbrYt0bf4OJjhDl03TaI6DYlTYJ< at >public.gmane.org>wrote:

_______________________________________________
Koha-devel mailing list
Koha-devel-yy2XUMoudrGBeeJdjao7tfCrwMbev77B< at >public.gmane.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Koha 3.8.1 released

Chris Cormack — 2012-05-21T21:32:25

The Koha release team is happy to announce the release of Koha 3.8.1

This is a stable release and contains bugfixes as well as updated translations.

You can download it at

http://download.koha-community.org/

Go forth, download, and enjoy :)


RELEASE NOTES FOR KOHA 3.8.1
21 May 2012
========================================================================

Koha is the first free and open source software library automation package
(ILS). Development is sponsored by libraries of varying types and sizes,
volunteers, and support companies from around the world.
The website for the Koha project is

    http://koha-community.org/

Koha 3.8.1 can be downloaded from:

    http://download.koha-community.org/koha-3.08.01.tar.gz

Installation instructions can be found:

   in the INSTALL files that come in the tarball

Koha 3.8.1 is a bugfix/maintenance release.

Highlights of 3.8.1
======================

7924criticalFix handling of command line arguments in koha-remove
7998critical3.8 UI cleanup, tweaks to new