Bug 12368 - Rebuild Zebra improvement: allow to specify a DB table
Summary: Rebuild Zebra improvement: allow to specify a DB table
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Command-line Utilities (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 15325
  Show dependency treegraph
 
Reported: 2014-06-05 10:28 UTC by Jonathan Druart
Modified: 2017-06-14 22:10 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 12368: Rebuild Zebra improvement: allow to specify a DB table (2.69 KB, patch)
2014-06-05 10:47 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 12368: Die if the --table value is not allowed. (1.56 KB, patch)
2014-06-12 07:40 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 12368: Rebuild Zebra improvement: allow to specify a DB table (2.75 KB, patch)
2014-12-28 07:06 UTC, Chris Cormack
Details | Diff | Splinter Review
Bug 12368: Die if the --table value is not allowed. (1.61 KB, patch)
2014-12-28 07:06 UTC, Chris Cormack
Details | Diff | Splinter Review
[PASSED QA] Bug 12368: Rebuild Zebra improvement: allow to specify a DB table (2.82 KB, patch)
2015-01-02 15:18 UTC, Kyle M Hall
Details | Diff | Splinter Review
[PASSED QA] Bug 12368: Die if the --table value is not allowed. (1.68 KB, patch)
2015-01-02 15:19 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Druart 2014-06-05 10:28:27 UTC
Currently the --where parameter only allow to specify a condition on fields in the biblioitems table.
For some needs it would be great to specify a condition on the field in the items table.
Comment 1 Jonathan Druart 2014-06-05 10:47:03 UTC Comment hidden (obsolete)
Comment 2 Mark Tompsett 2014-06-11 22:01:28 UTC
Shouldn't I be told that:
.../rebuild_zebra.pl -t stupid -b -a -r -v
is an invalid choice, rather than just correct to use biblioitems?
Comment 3 Jonathan Druart 2014-06-12 07:40:45 UTC Comment hidden (obsolete)
Comment 4 Jonathan Druart 2014-06-12 07:41:01 UTC
(In reply to M. Tompsett from comment #2)
> Shouldn't I be told that:
> .../rebuild_zebra.pl -t stupid -b -a -r -v
> is an invalid choice, rather than just correct to use biblioitems?

Yes, agreed.
Comment 5 Chris Cormack 2014-12-28 07:06:04 UTC Comment hidden (obsolete)
Comment 6 Chris Cormack 2014-12-28 07:06:28 UTC Comment hidden (obsolete)
Comment 7 Kyle M Hall 2015-01-02 15:18:59 UTC
Created attachment 34891 [details] [review]
[PASSED QA] Bug 12368: Rebuild Zebra improvement: allow to specify a DB table

Currently the --where parameter only allow to specify a condition on
fields in the biblioitems table.
For some needs it would be great to specify a condition on the field in
the items table.

The use case is the following: you want to reindex biblios with items
modified since a specific timestamp.

Test plan:
1/ Pick an item randomly in your catalogue
2/ Edit it and save
3/ Note that the items.timestamp has been set to today but not the
biblioitems.timestamp
4/ launch rebuild_zebra without the new parameter
  perl misc/migration_tools/rebuild_zebra.pl -b -v --where
  "timestamp >= XXX"
where XXX is the today date (e.g. "2014-06-05 00:00:00").
Note that the biblio has not been indexed.
5/ launch rebuild_zebra using the new parameter:
  perl misc/migration_tools/rebuild_zebra.pl -b -v -t items --where
  "timestamp >= XXX"
Note the biblio has been indexed.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 8 Kyle M Hall 2015-01-02 15:19:05 UTC
Created attachment 34892 [details] [review]
[PASSED QA] Bug 12368: Die if the --table value is not allowed.

If the table given in parameter is not in the white list, the script
should die rathen than correct to a default value.

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 9 Tomás Cohen Arazi 2015-02-05 18:05:09 UTC
Couldn't we just make the --where clause to apply to an inner join of both tables instead? This way we would avoid adding complexity.
We know those tables should be one if it didn't imply some performance penalty.

Setting to "In discussion", to discuss this idea.
Comment 10 Jonathan Druart 2015-02-06 09:02:05 UTC
(In reply to Tomás Cohen Arazi from comment #9)
> Couldn't we just make the --where clause to apply to an inner join of both
> tables instead? This way we would avoid adding complexity.
> We know those tables should be one if it didn't imply some performance
> penalty.

I didn't want to increase the execution time for other users.
Comment 11 Matthias Meusburger 2015-03-12 13:55:30 UTC
I tend to agree with Jonathan on this one:

  - It's better not to increase execution time when not needed.

  - This patch does not add that much complexity.

  - Wouldn't it add approximatively the same amount of complexity if using an inner joint?
Comment 12 Jonathan Druart 2015-09-22 10:36:48 UTC
Sending back to the RM queue.
Comment 13 Tomás Cohen Arazi 2015-10-09 17:34:32 UTC
Patches pushed to master.

Thanks Jonathan!
Comment 14 Fridolin Somers 2015-10-13 15:27:18 UTC
in my opinion, -t should not be used for --table, it is usually used for --test