IRC log for #koha, 2021-06-12

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
01:21 khall joined #koha
01:22 aleisha joined #koha
03:08 mtj hi Joubu: ive uploaded a Data::Session pkg, re bug 17427
03:08 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=17427 normal, P5 - low, ---, jonathan.druart+koha, Needs Signoff , Replace CGI::Session with Data::Session
06:55 cait joined #koha
06:58 paul_p__ joined #koha
09:20 cait tuxayo: hm maybe via the developer tools?
09:20 that's how i did it in the past
09:20 when testing without javascript
09:34 tuxayo cait: I tried with those tools to mess with JS and the HTML/DOM but couldn't find what to mess with to disable validation
09:35 Without JS the form doesn't show ^^"
09:44 cait oh
10:22 khall joined #koha
10:32 khall_ joined #koha
12:50 khall joined #koha
15:52 dpk_ joined #koha
16:01 JStal joined #koha
16:06 JStal Hello! Just discovered that our import_records table is 1.4GiB (!). Ran cleanup_database.pl --z3950 to clear it, expecting the table to truncate to a smaller size, but that didn't happen. Attempting to truncate through phpMyAdmin yields a foreign key error—what should I do to clean this up?
16:30 tuxayo hi JStal :)
16:31 Did the number of records from the table decreased with the cleanup?
16:31 JStal Hi! They did—the table has zero records now.
16:35 tuxayo JStal: that's actually surprising, --z3950 should not purge this table
16:35 https://git.koha-community.org[…]_database.pl#L708
16:40 JStal Interesting! You're right—my import_batches table is also clear. We don't often use the import function, instead relying on z39.50, so the import_batches table isn't very large. This post from Bywater indicates that cleanup might clear the import_records table, too? https://bywatersolutions.com/n[…]osing-weight-koha
16:44 "There’s also a hidden side to import_records. When you search another catalog using Z39.50 from the staff client, every record that gets returned is also stored in import_records. ... A recent update to Koha added the “–z3950” option to cleanup_database, which will purge all records coming from Z39.50 sources."
16:45 After switching to koha-shell and exporting PERL5LIB and KOHA_CONF I ran "perl /usr/share/koha/bin/cronjobs/cleanup_database.pl --z3950 --confirm" specifically. This may be the intended outcome, but I'm surprised that the table isn't truncated.
16:56 tuxayo JStal: so both table got their records purged?
16:56 the post doesn't mention import_batches so i'm confused
16:56 also
16:56 https://git.koha-community.org[…]_database.pl#L676
16:56 PurgeImportTables should help
16:58 https://mariadb.com/kb/en/optimize-table/
16:58 https://mariadb.com/kb/en/defr[…]nodb-tablespaces/
16:58 ↑↑ maybe it's the actual issue
16:58 cait i seem to remember that the dbms doesn't give the space up
16:58 when you truncate a table
16:59 tuxayo: is that what you were pointing out?
17:00 tuxayo cait: it's seems to be that. I did know there was that behaviour until searching that now.
17:01 cait I usually don't deal with that - just remember something our admin told me
17:05 JStal Sorry, I must have misunderstood. I thought the first link was demonstrating that the cleanup_database shouldn't clear import_records (but import_batches instead) with the --z3950 command. Line 676 seems to support that, but I only ran the command once, and the import_records table is now empty (but still large).
17:08 From https://mariadb.com/kb/en/defr[…]odb-tablespaces/: "Note that tablespace files (including ibdata1) will not shrink as the result of defragmentation, but one will get better memory utilization in the InnoDB buffer pool as there are fewer data pages in use."
17:09 Will this shrink the table on disk? I'm mostly concerned about speed, but that table is larger than every other table combined several times.
17:11 tuxayo > but I only ran the command once, and the import_records table is now empty
17:11 I don't know why both the cleaned. That's the odd thing right?
17:11 *both got cleaned
17:12 > Note that tablespace files (including ibdata1) will not shrink as the result of defragmentation
17:12 I guess it's OPTIMIZE TABLE that fits, then
17:13 JStal Definitely odd.
17:13 From OPTIMIZE: Note that tablespace files (including ibdata1) will not shrink as the result of defragmentation, but one will get better memory utilization in the InnoDB buffer pool as there are fewer data pages in use.
17:13 tuxayo I forgot to say that don't have experience with all of this ^^" Just finding stuff that seems to fit the current use case
17:19 JStal Oh, you've definitely moved me further than I was! I appreciate it. My searches were all Koha-specific, so I'll broaden them.
18:26 paul_p__ joined #koha
22:15 alexbuckley joined #koha
23:05 cait joined #koha

← Previous day | Today | Next day → | Search | Index

koha1