MDB2 Errors on Harvest
Getting this error on Debian Edge server. I missed the MDB2 requirements the first time around. Installed it through pear and got rid of all errors except the following when doing a harvest:
Fatal error: Call to undefined method MDB2_Error::prepare() in /usr/local/lib/locum/locum-server.php on line 98
Is there a version that needs to be installed to support prepare statements? Or something in php5 that might conflict with it? Here's the versions installed from pear. All the debian packages are what's in the official repos for stable w/ security updates.
MDB2 2.4.1 stable
MDB2_Driver_mysql 1.4.1 stable
MDB2_Driver_mysqli 1.4.1 stable
Ryan,
Can you verify that you're getting data out of xrecord? If the data being passed to MDB2 is malformed, that's the type of error it would throw.
for instance, When I go to:
http://irma.aadl.org:2082/xrecord=b1307278
I get an XML parse error. You should be getting clean XML. You might want to check with III about getting xrecord to work properly.
On the port 80 i have in the ini it seems to return things properly for the records that exist. I've tried changing the start and end to be two records i know exist and they still return the error.
http://irma.aadl.org/xrecord=b1054258
NM, i'm getting farther. looks like it might be failing to connect to the db but not giving any indication. I confirmed that the bib arrays are being populated right. I'll take a look at the DB part.
Yep, was just a connection error. Might want to through some sort of error there.
sometimes it's hard to tell with MDB2 because the errors it throws are pretty generic. I need to add better exception handling in future versions..
Are you able to harvest successfully now?
I can harvest fine now. harvested quite a few records. However when i did the index all most of the lines said 0 docs. Is that correct? For example:
indexing index 'bib_items_keyword'...
collected 0 docs, 0.0 MB
total 0 docs, 0 bytes
total 0.010 sec, 0.00 bytes/sec, 0.00 docs/sec
Hmm. The best way to troubleshoot indexing issues is to run the actual query that sphinx is doing for that index operation, so for the case of 'bib_items_keyword', try manually running:
SELECT bnum, author, addl_author, title, series, callnum, pub_year, stdnum, notes, subjects, \
CRC32(lang) AS lang, CRC32(loc_code) AS loc_code, CRC32(mat_code) AS mat_code, \
UNIX_TIMESTAMP(bib_created) AS bib_created, UNIX_TIMESTAMP(bib_lastupdate) AS bib_lastupdate, \
LOWER(title) AS title_ord, LOWER(author) AS author_ord, \
hold_count_week, hold_count_month, hold_count_year, hold_count_total, \
rating_idx, tag_idx, review_idx \
FROM locum_bib_items \
JOIN locum_holds_count USING (bnum) JOIN insurge_index USING (bnum) \
WHERE locum_bib_items.active = '1'
Also, did you check to make sure that the db username and password is set correctly for each index definition?
yep it's connecting. it looks like the join to the empty holds and empty index tables is making the set empty. if i remove the joins then it returns all the records. Is there something i should do first before running the indexer?
changed it to left joins and it works now
Ah that makes sense--I already had data when I adjusted that query. Mind posting your SQL?
exact same thing you have, just added LEFT in front of both joins. Once we get some tags and reviews i'll have to check and make sure it's still kicking
I tested it on my end and it slowed the indexing process down immensely to the point of unusability. I'll see what I can come up with...
Oh, my bad. You're going to want to change those back to regular JOINs, but before you run the indexing routine (and after you harvest your records), be sure to run the update-index.php script in your Insurge directory (/usr/local/lib/insurge/tools/update-index.php).
That will populate the index tables so you can run the sphinx indexer.
I'll update the docs to reflect this.