gerlowskija commented on PR #1793: URL: https://github.com/apache/solr/pull/1793#issuecomment-1658408834
> I think there's value in keeping SolrJ more focused on being a useful client for query & indexing that doesn't require Jackson... and having an "api" module on the side for doing all the other (often "admin") requests into Solr. I guess I just don't see a ton of user value in making that distinction. Is this all just to save users the pain of a Jackson version conflict, or the few extra MB it'd take to shade Jackson in SolrJ? The way I see it, there aren't tons and tons of users out there who query and index, but never need to create a collection. So whatever division we make to isolate the Jackson dep will be meaningless to a majority of our users. And the few users who _can_ take advantage of such a distinction, probably shouldn't anyway. Queries, etc. will probably be faster if they have Jackson available to use CBOR, the new transfer format Solr partially supports in 9.3. Depending how much you trust the [perf tests done here](https://issues.apache.org/jira/browse/SOLR-16812)), CBOR appears to be Solr's most efficient transfer format - a serious upgrade over javabin that anyone concerned about latency is going to want to try. But that's just my take 🤷 > If I spend some time figuring out how to iterate on this PR to keep SolrJ free of this stuff (particularly Jackson) by solving the "multi-step code generation" or whatever to keep "api" separate (and with no inward dependency from SolrJ) -- would that be appreciated? For sure! If you find a reasonably elegant way around the "multi-step code generation" thing, or find a way to avoid the extra module, I'm all for that. I've been trying to bait folks into double-checking my sketchy gradle work throughout 😛 (Thanks to Houston for all the help so far!) As I said, I'm personally skeptical of the value prop in creating a new user-facing module just for the purpose of segregating our Jackson surface area. But if there's solid consensus around that, and you're willing to look into it, I'm open to being the minority there as well. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
