Description
Jonathan Druart
2014-06-05 10:28:27 UTC
Created attachment 28672 [details] [review] 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. 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? Created attachment 28793 [details] [review] 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. (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. Created attachment 34749 [details] [review] 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> Created attachment 34750 [details] [review] 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> 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> 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> 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. (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. 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? Sending back to the RM queue. Patches pushed to master. Thanks Jonathan! in my opinion, -t should not be used for --table, it is usually used for --test |