bugs(?) in SolrSearch plugin

[Maurice Bouchard]

Hello,

I'm running Omeka 1.5 and checked out the latest SolrSearch plugin source from svn.  I found a couple of bugs and a couple of things that could be bugs.  I'm not sure this is the correct place for reporting the bugs but I don't see anything on the Omeka site or the ScholarsLab site.  Someone will set me straight if I'm in the wrong place :-)

First the bugs:

Line 221 and 223 in /helpers/SolrSearchFunctions.php have $#022; for the closing quote around the facet.  It should be 

Second, the questionable behavior:

Solr is working fine with Omeka data outside of Omeka, i.e., through the solr admin tools.  The plugin, though, seems to form queries incorrectly, for example, searching for 'fabric' on my site, I get no results; the search query is

http://calliope.simmons.edu/omeka/solr-search/results/?textinput=fabric&solrfacet=&submit_search=Search

Changing the 'textinput' to 'solrq' solves the problem, as in, http://calliope.simmons.edu/omeka/solr-search/results/?solrq=fabric&solrfacet=&submit_search=Search  Is this a valid fix?  I'm not sure what a valid query is supposed to look like.  It feels like a hack to me.  Similarly, clicking on a facet yielded a malformed query with /?solrfacet=  Again if I changed ?solrfacet= to ?solrq=  I'm laughing but I don't know why.  Lastly, I still have an issue with searching for a keyword AND a facet.  I get a query string like:

http://calliope.simmons.edu/omeka/solr-search/results/?solrq=fabric&solrq=+AND+collection:%22HNE%20Gropius%20House%22

The "+AND+" seems to be the problem.  Removing that manually in the URL input box gives a good result, but I haven't found it in the code yet.

I am running multicore Solr 3.5  You can see the admin for each core (omeka and virginia) at calliope.simmons.edu:8081/solr if that helps.

Regards,

Maury Bouchard

Simmons GSLIS - DCL

[Wayne Graham]

Hi Maury,

The latest SolrSearch got moved over to Github
(https://github.com/scholarslab/SolrSearch), but I believe you have
found a bug. The latest Solr we've tested this is 3.1.0, and I know
there has been some updates to the syntax.

I'll try to clear out some time tomorrow to take a look at what's
going on and add a ticket or two on the issue tracker
(https://github.com/scholarslab/SolrSearch/issues).

Cheers,
Wayne

/**
 * @author Wayne Graham
 * @link http://www.liquidfoot.com
 */

> --
> You received this message because you are subscribed to the Google Groups
> "Omeka Dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/omeka-dev/-/d8hCKS5WKwgJ.
> To post to this group, send email to omek...@googlegroups.com.
> To unsubscribe from this group, send email to
> omeka-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/omeka-dev?hl=en.

[Maurice Bouchard]

Thanks, Wayne. I'd rather use git anyway.  Also, I'm happy to do some testing if it that helps you. The link on http://omeka.org/codex/Plugins/SolrSearch still points at svn.  Is that something you can change or should I email someone else.

Best,

Maury

[Wayne Graham]

Hi Maury,

I thought that had gotten hidden with the rollout of the new Plugin
pages (http://omeka.org/add-ons/plugins/solrsearch/).

Patrick, do those codex plugin pages still need to be maintained?

Cheers,
Wayne

/**
 * @author Wayne Graham
 * @link http://www.liquidfoot.com
 */

[Maurice Bouchard]

Hi Wayne,

The new plugin page only has version 0.8 of the plugin. Version 1.0 on the codex page doesn't include config_form.php.  If it wasn't for pulling the source code I wouldn't have made the progress I did make.

Best,

Maury

[Wayne Graham]

Hi Maury,

Yeah, that package was an optimistic 1.0 release and isn't the 'real'
version (a prebuilt snapsnot). The most up-to-date version is on
git...

Wayne

/**
 * @author Wayne Graham
 * @link http://www.liquidfoot.com
 */

[Wayne Graham]

Maury,

I took some time this morning to take a look at this issue and I
believe these are addressed in the github version. Would you mind
testing that version out? You'll need to completely uninstall the
plugin first...

Cheers,
Wayne

/**
 * @author Wayne Graham
 * @link http://www.liquidfoot.com
 */

[Maurice Bouchard]

Beautiful!  Thanks.  Sure, I'd love to test it but I won't be able to do it until Monday.  I'll let you know.

Have a great weekend,

Maury

[Thomas Krichel]

Hi omeka gurus!

I migrated a bunch of student sites from one box to another. Most
were version 1.4.2. They work without a hitch. But some are 1.5
version installations.

There I find

manija@tiu:~$ php omeka/index.php > /dev/null
PHP Strict Standards: Declaration of ImageAnnotationPermissionsManager::getInstance() should be compatible with ImageAnnotationAbstractPermissionsManager::getInstance($pluginName) in /home/manija/omeka-1.5/plugins/ImageAnnotation/permissions-manager.php on line 4
Omeka fatal error: exception 'Zend_Db_Statement_Mysqli_Exception' with message 'Mysqli prepare error: Table 'manija.omeka_sessions' doesn't exist' in /home/manija/omeka-1.5/application/libraries/Zend/Db/Statement/Mysqli.php:77
Stack trace:
#0 /home/manija/omeka-1.5/application/libraries/Zend/Db/Statement.php(115): Zend_Db_Statement_Mysqli->_prepare('SELECT `omeka_s...')
#1 /home/manija/omeka-1.5/application/libraries/Zend/Db/Adapter/Mysqli.php(381): Zend_Db_Statement->__construct(Object(Zend_Db_Adapter_Mysqli), 'SELECT `omeka_s...')
#2 /home/manija/omeka-1.5/application/libraries/Zend/Db/Adapter/Abstract.php(478): Zend_Db_Adapter_Mysqli->prepare('SELECT `omeka_s...')
#3 /home/manija/omeka-1.5/application/libraries/Zend/Db/Table/Abstract.php(1529): Zend_Db_Adapter_Abstract->query(Object(Zend_Db_Table_Select))
#4 /home/manija/omeka-1.5/application/libraries/Zend/Db/Table/Abstract.php(1344): Zend_Db_Table_Abstract->_fetch(Object(Zend_Db_Table_Select))
#5 /home/manija/omeka-1.5/application/libraries/Zend/Db/Table/Abstract.php(1309): Zend_Db_Table_Abstract->fetchAll('((`omeka_sessio...')
#6 [internal function]: Zend_Db_Table_Abstract->find('rs8dqqsdcm5nb0b...')
#7 /home/manija/omeka-1.5/application/libraries/Zend/Session/SaveHandler/DbTable.php(318): call_user_func_array(Array, Array)
#8 [internal function]: Zend_Session_SaveHandler_DbTable->read('rs8dqqsdcm5nb0b...')
#9 /home/manija/omeka-1.5/application/libraries/Zend/Session.php(469): session_start()
#10 /home/manija/omeka-1.5/application/libraries/Zend/Session/Namespace.php(143): Zend_Session::start(true)
#11 /home/manija/omeka-1.5/application/libraries/Zend/Auth/Storage/Session.php(87): Zend_Session_Namespace->__construct('Zend_Auth')
#12 /home/manija/omeka-1.5/application/libraries/Zend/Auth.php(91): Zend_Auth_Storage_Session->__construct()
#13 /home/manija/omeka-1.5/application/libraries/Zend/Auth.php(141): Zend_Auth->getStorage()
#14 /home/manija/omeka-1.5/application/libraries/Omeka/Core/Resource/Currentuser.php(44): Zend_Auth->hasIdentity()
#15 /home/manija/omeka-1.5/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(683): Omeka_Core_Resource_Currentuser->init()
#16 /home/manija/omeka-1.5/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(629): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource('Currentuser')
#17 /home/manija/omeka-1.5/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(586): Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap('Currentuser')
#18 /home/manija/omeka-1.5/application/libraries/Omeka/Core/Resource/Helpers.php(128): Zend_Application_Bootstrap_BootstrapAbstract->bootstrap('Currentuser')
#19 /home/manija/omeka-1.5/application/libraries/Omeka/Core/Resource/Helpers.php(21): Omeka_Core_Resource_Helpers->_initAclHelper()
#20 /home/manija/omeka-1.5/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(683): Omeka_Core_Resource_Helpers->init()
#21 /home/manija/omeka-1.5/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(629): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource('Helpers')
#22 /home/manija/omeka-1.5/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(586): Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap('Helpers')
#23 /home/manija/omeka-1.5/application/libraries/Omeka/Core/Resource/Frontcontroller.php(45): Zend_Application_Bootstrap_BootstrapAbstract->bootstrap('Helpers')
#24 /home/manija/omeka-1.5/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(683): Omeka_Core_Resource_Frontcontroller->init()
#25 /home/manija/omeka-1.5/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(626): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource('frontcontroller')
#26 /home/manija/omeka-1.5/application/libraries/Zend/Application/Bootstrap/BootstrapAbstract.php(586): Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap(NULL)
#27 /home/manija/omeka-1.5/application/libraries/Zend/Application.php(355): Zend_Application_Bootstrap_BootstrapAbstract->bootstrap(NULL)
#28 /home/manija/omeka-1.5/application/libraries/Omeka/Core.php(114): Zend_Application->bootstrap()
#29 /home/manija/omeka-1.5/index.php(28): Omeka_Core->initialize()
#30 {main}
PHP Fatal error: Uncaught exception 'Zend_Db_Statement_Mysqli_Exception' with message 'Mysqli prepare error: Table 'manija.omeka_sessions' doesn't exist' in /home/manija/omeka-1.5/application/libraries/Zend/Db/Statement/Mysqli.php:77
Stack trace:
#0 /home/manija/omeka-1.5/application/libraries/Zend/Db/Statement.php(115): Zend_Db_Statement_Mysqli->_prepare('SELECT `omeka_s...')
#1 /home/manija/omeka-1.5/application/libraries/Zend/Db/Adapter/Mysqli.php(381): Zend_Db_Statement->__construct(Object(Zend_Db_Adapter_Mysqli), 'SELECT `omeka_s...')
#2 /home/manija/omeka-1.5/application/libraries/Zend/Db/Adapter/Abstract.php(478): Zend_Db_Adapter_Mysqli->prepare('SELECT `omeka_s...')
#3 /home/manija/omeka-1.5/application/libraries/Zend/Db/Table/Abstract.php(1529): Zend_Db_Adapter_Abstract->query(Object(Zend_Db_Table_Select))
#4 /home/manija/omeka-1.5/application/libraries/Zend/Db/Table/Abstract.php(1344): Zend_Db_Table_Abstract->_fetch(Object(Zend_Db_Table_Select))
#5 /home/manija/omeka-1.5/application/libraries/Zend/Db/Table/Abstract. in /home/manija/omeka-1.5/application/libraries/Zend/Db/Statement/Mysqli.php on line 77

But

manija@tiu:~$ echo "use manija; show tables" | mysql | grep sessions
omeka_sessions

shows that the table exists. I am very confused. Any ideas?

Cheers,

Thomas Krichel http://openlib.org/home/krichel
http://authorprofile.org/pkr1
skype: thomaskrichel

[Maurice Bouchard]

Wayne,

I cloned the repository at https://github.com/scholarslab/SolrSearch  but found that the html entity for the closing quote at lines 221 and 223 in /helpers/SolrSearchFunctions.php is still incorrect; the entity begins with $ instead &  I didn't go any further because now I'm not sure if I cloned from the right place.

Let me know.

Maury

[Wayne Graham]

Hi Maury,

Sorry about that...I was looking at a different branch. I just merged
that change in to the master branch. Try pulling on master...

Cheers,
Wayne

/**
 * @author Wayne Graham
 * @link http://www.liquidfoot.com
 */

[John Flatness]

On 04/06/2012 01:11 PM, Thomas Krichel wrote:
>
> Omeka fatal error: exception 'Zend_Db_Statement_Mysqli_Exception' with message 'Mysqli prepare error: Table 'manija.omeka_sessions' doesn't exist' in /home/manija/omeka-1.5/application/libraries/Zend/Db/Statement/Mysqli.php:77
>

> ...

>
> But
>
> manija@tiu:~$ echo "use manija; show tables" | mysql | grep sessions
> omeka_sessions
>
> shows that the table exists. I am very confused. Any ideas?
>

You've shown some output confirming that you have the omeka_sessions
table, but it actually being missing in the database Omeka's accessing
is the only thing I can think of to explain this. Omeka 1.5 doesn't do
anything fancy or different in accessing the database.

Is it possible that you ran your "grep sessions" on the old copy, not
the new, or that your db.ini's not pointing to the same database you ran
that test against, or something similarly trivial? Those are the only
options that immediately come to mind.

-John

[Thomas Krichel]

John Flatness writes

> You've shown some output confirming that you have the omeka_sessions
> table, but it actually being missing in the database Omeka's
> accessing is the only thing I can think of to explain this.

I can see the files in the /var/lib/mysql/foo files.

> Omeka 1.5 doesn't do anything fancy or different in accessing the
> database.

I suppose not ;-)

> Is it possible that you ran your "grep sessions" on the old copy,
> not the new, or that your db.ini's not pointing to the same database
> you ran that test against, or something similarly trivial?

I migrated from one installation of Debian testing to another one
on a different box. I rsynced /var/lib/mysql and /etc/mysql,
that allows access for the debian-sys-maint user.

Only the 1.5 installations failed. The way I rid myself of this
issue and to proceed with other aspects of my life was to downgrade
the installations of all students having 1.5 to 1.4.2. These
students all had 1.4.2 installed before and I was prudent enough to
remove it.

Thus I did something like (from memory)

rsync -va /home/foo/omeka-1.5/archive/ /home/foo/omeka-1.4.2/archive
rm /home/foo/omeka
ln -s /home/foo/omeka-1.4.2 /home/foo/omeka

and changed to /etc/apache2/conf/omeka_foo, from

Alias /omeka/foo/ /home/foo/omeka-1.5/
<Directory /home/foo/omeka-1.5/>
Options +FollowSymLinks
AllowOverride all
order allow,deny
allow from all
</Directory>

to

Alias /omeka/foo/ /home/foo/omeka-1.4.2/
<Directory /home/foo/omeka-1.4.2/>
Options +FollowSymLinks
AllowOverride all
order allow,deny
allow from all
</Directory>

The 1.5 modified database seems to work under 1.4.2. Well, no
student has complained as yet!

BTW, I find it puzzling that I can't seem to say

Alias /omeka/foo/ /home/foo/omeka/
<Directory /home/foo/omeka/>
Options +FollowSymLinks
AllowOverride all
order allow,deny
allow from all
</Directory>

This would allow the symlink to say what version is used, and allow
students to ugrade their sites without root intervention. But I
understand that's an apache issue. If I was smart I'd use
nginx ;-)

> Those are the only options that immediately come to mind.

Thank you so much for your help. If you make it to NYC, let me know,
I will be happy to have you as my guest.

ok, enough sysadmin talk ;-)

[Wayne Graham]

Weird that the symlinks aren't working, we use capistrano style
deployment structures which are similar to what you're wanting to do,
but don't symlink it to home directory. Basically upgrades are

unlink current && ln -s /path/to/new/omeka/releases/new_version current

And the debian sites just has a pointer to current as the doc root.

What do the group perms look like? You could just chgrp to give access that way.

You may also want to try a mysqldump in to a new database and pointing
the db.ini there to do an upgrade. I've never experienced a missing
table in there, but you may also try just getting the DDL for the
tables and making that one manually...

HTH,
Wayne

/**
 * @author Wayne Graham
 * @link http://www.liquidfoot.com
 */

[Maurice Bouchard]

Hi Wayne,

Sorry, but this now worse than it was.  The html entities are fixed but now I can't even get to the point of getting to the facets.  If I browse for all items using the URI specified in http://omeka.org/codex/Plugins/SolrSearch, that is, http://calliope.simmons.edu/omeka/solr-search/results/?q=*:* (which was working before) I get fatal errors with the following in the errors.log file

2012-04-10T15:28:42-04:00 ERR (3): exception 'Apache_Solr_HttpTransportException' with message ''400' Status: Bad Request' in /gslis/omeka-1.5/plugins/SolrSearch/lib/Service.php:338

Stack trace:

#0 /gslis/omeka-1.5/plugins/SolrSearch/lib/Service.php(1170): Apache_Solr_Service->_sendRawGet('http://localhos...')

#1 /gslis/omeka-1.5/plugins/SolrSearch/controllers/ResultsController.php(162): Apache_Solr_Service->search('*:* AND (image:...', 0, '20', Array)

#2 /gslis/omeka-1.5/plugins/SolrSearch/controllers/ResultsController.php(54): SolrSearch_ResultsController->search(Array, 0, '20')

#3 /gslis/omeka-1.5/plugins/SolrSearch/controllers/ResultsController.php(38): SolrSearch_ResultsController->handleHtml()

#4 /gslis/omeka-1.5/application/libraries/Zend/Controller/Action.php(516): SolrSearch_ResultsController->indexAction()

#5 /gslis/omeka-1.5/application/libraries/Zend/Controller/Dispatcher/Standard.php(295): Zend_Controller_Action->dispatch('indexAction')

#6 /gslis/omeka-1.5/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))

#7 /gslis/omeka-1.5/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()

#8 /gslis/omeka-1.5/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()

#9 /gslis/omeka-1.5/application/libraries/Omeka/Core.php(165): Zend_Application->run()

#10 /gslis/omeka-1.5/index.php(28): Omeka_Core->run()

#11 {main}

and from my catalina.out file:

Apr 10, 2012 3:44:48 PM org.apache.solr.common.SolrException log

SEVERE: org.apache.solr.common.SolrException: org.apache.lucene.queryParser.ParseException: Cannot parse '*:* AND (image:* OR *:*)': '*' or '?' not allowed as first character in WildcardQuery

        at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:125)

        at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:173)

        at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)

        at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)

        at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)

        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)

        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)

        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)

        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)

        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)

        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)

        at java.lang.Thread.run(Thread.java:680)

Caused by: org.apache.lucene.queryParser.ParseException: Cannot parse '*:* AND (image:* OR *:*)': '*' or '?' not allowed as first character in WildcardQuery

Let me know what other information I can provide.

Maury

[Wayne Graham]

Hi Maury,

Mind if we bump this over to a ticket?
https://github.com/scholarslab/SolrSearch/issues/6

You may need to delete the index and reindex the entire collection
(see https://gist.github.com/2355797 for a gist to delete the index).

At first glance, there may be a configuration issue somewhere (the
SEVERE: org.apache.solr.common.SolrException:
org.apache.lucene.queryParser.ParseException: Cannot parse ': AND
(image:* OR :)': '' or '?' not allowed as first character in
WildcardQuery) where some extra stuff is going in to the system.

I'll follow up more on that ticket...

Cheers,
Wayne

/**
 * @author Wayne Graham
 * @link http://www.liquidfoot.com
 */