Having a little trouble with bag-queries.xml

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Having a little trouble with bag-queries.xml

joe carlson
Hello,

I was having a little trouble tweaking bag-queries.xml. I think I've
figured it out now, but still wanted to run this by you folks to see if
this makes sense.

the existing structure is

<bag-queries>
   <bag-type type="BioEntity" matchOnFirst="true">
    ....queries...
   </bag-type>
</bag-queries>

I was hoping I'd be able to subclass this and add some new <bag-type>
entries that would specialize it for a particular type of bioentity. In
my particular case, for a SNP, I'd like to search only on the exact name
(it's a big table) so I added

  <bag-type type="SNP" matchOnFirst="true" runBeforeDefault="true" >
     <query message="searching name field only" matchesAreIssues="true" >
         SELECT DISTINCT a1_.id as a2_, a1_.name as a3_ FROM SNP AS a1_
WHERE a1_.name in ?
     </query>
   </bag-type>

but after building and deploying, I was getting a tomcat error:

Jan 06, 2016 5:20:19 PM org.apache.catalina.core.ApplicationContext log
SEVERE: action: null
java.lang.NullPointerException
     at
org.intermine.web.struts.InitialiserPlugin.loadBagQueries(InitialiserPlugin.java:543)
     at
org.intermine.web.struts.InitialiserPlugin.loadInterMineAPI(InitialiserPlugin.java:281)
     at
org.intermine.web.struts.InitialiserPlugin.init(InitialiserPlugin.java:189)
     at
org.apache.struts.action.ActionServlet.initModulePlugIns(ActionServlet.java:871)
     at org.apache.struts.action.ActionServlet.init(ActionServlet.java:359)
     at javax.servlet.GenericServlet.init(GenericServlet.java:158)

With a bit of work I was seeing that the BagQueryHandler will process
the type="BioEntity" bag-type and apply it to all subclasses. When it
BagQueryHandler the type="SNP" entry, the handler throws an exception
complaining that there is already a query defined for this type. The
result of this is that bagQueryConfig was null.

If I add the type="SNP" bag-type before the type="BioEntity", then
things are OK. Do you think it would be OK to have a SNP entry overwrite
something inherited from BioEntity, rather than counting on placement
within the XML determine this?

But a couple of remaining questions are:

for the type="BioEntity", you have 3 queries, each of which is more
complex. Is the idea that if matchOnFirst="true" is set then the queries
after this are not run on items that have been found? Or are later
queries not run on any item?

And the runBeforeDefault="false" is set. So these are run after the
default. I was having trouble seeing where the default query is set.
Where is this?

Finally, what does "matchesAreIssues" do?

Thanks. You've always been helpful,

Joe



_______________________________________________
dev mailing list
[hidden email]
http://mail.intermine.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Having a little trouble with bag-queries.xml

Julie Sullivan


On 07/01/16 02:51, Joe Carlson wrote:

> Hello,
>
> I was having a little trouble tweaking bag-queries.xml. I think I've
> figured it out now, but still wanted to run this by you folks to see if
> this makes sense.
>
> the existing structure is
>
> <bag-queries>
>    <bag-type type="BioEntity" matchOnFirst="true">
>     ....queries...
>    </bag-type>
> </bag-queries>
>
> I was hoping I'd be able to subclass this and add some new <bag-type>
> entries that would specialize it for a particular type of bioentity. In
> my particular case, for a SNP, I'd like to search only on the exact name
> (it's a big table) so I added
>
>   <bag-type type="SNP" matchOnFirst="true" runBeforeDefault="true" >
>      <query message="searching name field only" matchesAreIssues="true" >
>          SELECT DISTINCT a1_.id as a2_, a1_.name as a3_ FROM SNP AS a1_
> WHERE a1_.name in ?
>      </query>
>    </bag-type>
>
> but after building and deploying, I was getting a tomcat error:
>
> Jan 06, 2016 5:20:19 PM org.apache.catalina.core.ApplicationContext log
> SEVERE: action: null
> java.lang.NullPointerException
>      at
> org.intermine.web.struts.InitialiserPlugin.loadBagQueries(InitialiserPlugin.java:543)
>
>      at
> org.intermine.web.struts.InitialiserPlugin.loadInterMineAPI(InitialiserPlugin.java:281)
>
>      at
> org.intermine.web.struts.InitialiserPlugin.init(InitialiserPlugin.java:189)
>      at
> org.apache.struts.action.ActionServlet.initModulePlugIns(ActionServlet.java:871)
>
>      at org.apache.struts.action.ActionServlet.init(ActionServlet.java:359)
>      at javax.servlet.GenericServlet.init(GenericServlet.java:158)
>
> With a bit of work I was seeing that the BagQueryHandler will process
> the type="BioEntity" bag-type and apply it to all subclasses. When it
> BagQueryHandler the type="SNP" entry, the handler throws an exception
> complaining that there is already a query defined for this type. The
> result of this is that bagQueryConfig was null.
>
> If I add the type="SNP" bag-type before the type="BioEntity", then
> things are OK. Do you think it would be OK to have a SNP entry overwrite
> something inherited from BioEntity, rather than counting on placement
> within the XML determine this?

Yes! That is a bug. oops.

> But a couple of remaining questions are:
>
> for the type="BioEntity", you have 3 queries, each of which is more
> complex. Is the idea that if matchOnFirst="true" is set then the queries
> after this are not run on items that have been found? Or are later
> queries not run on any item?

This page should help with some of your questions:

http://intermine.readthedocs.org/en/latest/webapp/lists/list-upload/

If matchOnFirst is set to be TRUE, further queries are not run on that
specific item if a query returns a match.

What the code actually does when matchOnFirst = TRUE

* run query 1 for all items in list of identifiers
* remove matched items from list of identifiers
* run query 2 for all items in  list of identifiers
* remove matched items from list of identifiers
* .. etc.

In the case where matchOnFirst = FALSE, all queries are run for all items.

> And the runBeforeDefault="false" is set. So these are run after the
> default. I was having trouble seeing where the default query is set.
> Where is this?

The default query searches for the value in key fields. The key fields
are set by class_keys.properties.

> Finally, what does "matchesAreIssues" do?

Matches returned from this query are not added to the list (if
matchesAreIssues=true), they are displayed under the “synonyms matched”
heading. Users can optionally add them to their list.

Only relevant for list upload, not LOOKUPs.

> Thanks. You've always been helpful,
>
> Joe
>
>
>
> _______________________________________________
> dev mailing list
> [hidden email]
> http://mail.intermine.org/cgi-bin/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
[hidden email]
http://mail.intermine.org/cgi-bin/mailman/listinfo/dev