You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Jason Gerlowski (JIRA)" <ji...@apache.org> on 2018/10/31 18:18:01 UTC

[jira] [Commented] (SOLR-12947) SolrJ Helper for JSON Request API

    [ https://issues.apache.org/jira/browse/SOLR-12947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670485#comment-16670485 ] 

Jason Gerlowski commented on SOLR-12947:
----------------------------------------

There's a few general approaches we can take with a {{JsonQueryRequest}} class.  The main question is how the JSON request body gets constructed.

1. {{JsonQueryRequest}} can have setters which assign fields based on primitives or other more structured classes (Map<String,Object>).  This is pretty simple/easy and is resilient to future syntax/schema changes to boot.  More advanced (nested) queries would have to be supported by taking in Maps constructed by users, so users aren't completely abstracted from the JSON schema.  So that's a downside.  But this can be mitigated in ways too.
2. {{JsonQueryRequest}} would use a small library of "bean"/annotated-POJO classes. Users would construct an object-graph to represent their JSON query which would then be converted to JSON by Jackson or some other library.  This might be the best for users if done well, but it would require vigilance to ensure that the bean-classes stay up to date with future DSL syntax changes.  It might also require adding jackson or some other json serde library as a SolrJ dependency, which would suck.
3. {{JsonQueryRequest}} would still use a user-provided String as the whole request body, but would utilize the request DSL's macro-expansion capabilities to make this hardcoded string a bit more flexible.  This option gets us the least, but is also the least work.  I don't think it's worth discarding entirely though.  There are some use-cases where it's more convenient: e.g if a user typically runs a small number of very complex queries, it's possibly easier to construct these as Strings rather than building a deep object graph for each.

> SolrJ Helper for JSON Request API
> ---------------------------------
>
>                 Key: SOLR-12947
>                 URL: https://issues.apache.org/jira/browse/SOLR-12947
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: clients - java, SolrJ
>    Affects Versions: 7.5
>            Reporter: Jason Gerlowski
>            Assignee: Jason Gerlowski
>            Priority: Minor
>
> The JSON request API is becoming increasingly popular for sending querying or accessing the JSON faceting functionality. The query DSL is simple and easy to understand, but crafting requests programmatically is tough in SolrJ. Currently, SolrJ users must hardcode in the JSON body they want their request to convey.  Nothing helps them build the JSON request they're going for, making use of these APIs manual and painful.
> We should see what we can do to alleviate this.  I'd like to tackle this work in two pieces.  This (the first piece) would introduces classes that make it easier to craft non-faceting requests that use the JSON Request API.  Improving JSON Faceting support is a bit more involved (it likely requires improvements to the Response as well as the Request objects), so I'll aim to tackle that in a separate JIRA to keep things moving.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org