You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by GitBox <gi...@apache.org> on 2021/04/19 02:31:40 UTC
[GitHub] [solr] gerlowskija opened a new pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
gerlowskija opened a new pull request #81:
URL: https://github.com/apache/solr/pull/81
This commit converts MODIFYCOLLECTION, the first of the /v2/c/<coll>
APIs. None of the other APIs have been touched (yet), just for lack of
time. This leaves RELOAD, MOVEREPLICA, MIGRATEDOCS, BALANCESHARDUNIQUE,
REBALANCELEADERS, ADDREPLICAPROPERTY, DELETEREPLICAPROPERTY,
and SETCOLLECTIONPROPERTY.
When all these are added, tests are still needed and the apispec file
containing them all needs deleted.
# Description
Solr has two mechanisms for implementing v2 APIs: an apispec (i.e. JSON file) based approach, and a newer approach that uses annotated POJOs. A consensus has emerged across many JIRAs that the latter approach is preferable going forward, since it reduces duplication and inches the code closer to strongly-typed APIs. But moving existing APIs over to this new mechanism is a big task.
# Solution
This PR aims to migrated Solr's `/v2/collections/<collection>` APIs to the new preferred mechanism.
# Tests
See the (as yet unimplemented) tests in `V2SpecificCollectionAPIMappingTest`
# Checklist
Please review the following and check all that apply:
- [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability.
- [x] I have created a Jira issue and added the issue ID to my pull request title.
- [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended)
- [x] I have developed this patch against the `main` branch.
- [ ] I have run `./gradlew check`.
- [ ] I have added tests for my changes.
- [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide)
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] gerlowskija commented on a change in pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
gerlowskija commented on a change in pull request #81:
URL: https://github.com/apache/solr/pull/81#discussion_r623862243
##########
File path: solr/core/src/java/org/apache/solr/handler/SpecificCollectionAPI.java
##########
@@ -0,0 +1,89 @@
+package org.apache.solr.handler;
+
+import org.apache.solr.api.Command;
+import org.apache.solr.api.EndPoint;
+import org.apache.solr.api.PayloadObj;
+import org.apache.solr.client.solrj.request.beans.BackupCollectionPayload;
+import org.apache.solr.client.solrj.request.beans.ModifyCollectionPayload;
+import org.apache.solr.common.cloud.ZkStateReader;
+import org.apache.solr.common.params.CollectionParams;
+import org.apache.solr.handler.admin.CollectionsHandler;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import static org.apache.solr.client.solrj.SolrRequest.METHOD.DELETE;
+import static org.apache.solr.client.solrj.SolrRequest.METHOD.POST;
+import static org.apache.solr.cloud.api.collections.CollectionHandlingUtils.REQUESTID;
+import static org.apache.solr.common.params.CollectionAdminParams.COLLECTION;
+import static org.apache.solr.common.params.CommonParams.ACTION;
+import static org.apache.solr.common.params.CommonParams.NAME;
+import static org.apache.solr.handler.ClusterAPI.wrapParams;
+import static org.apache.solr.security.PermissionNameProvider.Name.COLL_EDIT_PERM;
+
+
+// TODO This classname sucks - I'm trying to convey that the APIs in this class all operate on a single specific
Review comment:
Hah, yeah no worries. I'm as revolted by the name as it sounds like you are 😛 I really just needed a placeholder to get started.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] gerlowskija edited a comment on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
gerlowskija edited a comment on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-860611843
> BTW I would have reviewed if you prompted me. It was on the back of my mind already.
Oh, my bad. I thought about pinging you, but didn't want to be a bother (I'd tagged you once already in a recent comment, and didn't want to push it.) It's never too late though - if there's anything you're particularly concerned about lmk and I can take a look.
> In these source files, why did you declare constants ... Referenced only in the command annotation
There's only one usage _right now_, but there's likely to be other places where this string will be used eventually as v2 support progresses. Additional tests might use it, SolrJ will need to use it to make v2 requests at some point, etc. So to the extent I thought about it at all, that was probably my motivation. If you know for certain that something will only ever be used once - definitely agree the constant is useless. But in practice I rarely ever feel like I _know_ that, and in this case there's particular reason to expect additional usages in the future.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] noblepaul commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
noblepaul commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-834084518
thanks @gerlowskija
other than the class name it looks fine
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dsmiley commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
dsmiley commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-860850526
Ok that's fine.
BTW this PR is just awesomeness!
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] gerlowskija commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
gerlowskija commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-850584543
> Any of the remaining APIs would be great if the offer still stands - maybe ADDREPLICAPROPERTY and/or DELETEREPLICAPROPERTY ?
Returning to this now - if I don't finish converting the commands today I'll post the remainder in case you get a few minutes to chip in David.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dsmiley commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
dsmiley commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-832982178
Yes I do feel strongly that they get their own class. That solves your naming conundrum :-)
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dsmiley commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
dsmiley commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-859841902
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dsmiley commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
dsmiley commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-833915868
If I could be of help, then assign me to do one of the commands and I'll push to your PR.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] gerlowskija commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
gerlowskija commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-830093740
> Do we really need all command endpoints in this one class, which I believe is your intention to do?
That was my intention, yep - based mostly on how I read the existing convention with these files. But I'm not strongly attached to that or anything.
If we put the API logic itself in these files, then I definitely agree that each command would benefit from its own file. But we're pretty far from that right now - right now FooAPi is just v2->v1 conversion logic. And in the current form I think the "by path" grouping is reasonable. Or at the very least, it does no harm.
So I'm ambivalent currently. If you feel strongly that each of these gets its own class, and you think there's benefits to that even before we split up the CollectionsHandler logic, then I'm open to going that route.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] gerlowskija merged pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
gerlowskija merged pull request #81:
URL: https://github.com/apache/solr/pull/81
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] gerlowskija commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
gerlowskija commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-851110170
I've finished the APIs themselves and have tests for each of the v1->v2 conversions. The last thing to be done here I think is splitting up the API commands into separate classes as per @dsmiley's feedback.
On that note - there's a bug that complicates doing this right now. Each API class is registered individually by "ApiBag", which stores an Api object per HTTP method, per path. When all commands for a given method and path are in the same class - this works well. When commands for that method and path are split across different classes though - the registration for each one overrides the registrations before it.
I've highlighted the line where this happens [here](https://github.com/apache/solr/pull/81/files#diff-20733c59d42a1a1a2b4164485888dc067db372fa2c7fdffb30d48c04ae2bed74R168), and suggested a few workarounds. All of them seem a bit hacky at first glance. Maybe one of the suggestions there is good enough, but I don't have tons of context on ApiBag (and the PathTrie class it relies on) and need to give it a bit more thought to know which is best.
@noblepaul any suggestions on the best way to handle this? Or am I missing something else that'd get me around this?
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] gerlowskija commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
gerlowskija commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-854319415
I've tentatively pushed a fix for the api-overwriting problem I described in my last comment. The fix I ended up using is as follows:
1. Add a method to PathTrie, `attachValueToNode`, to encapsulate storing an object at a given node. As written in PathTrie this storage uses the same "overwriting" semantics that PathTrie has had up to this point. But having this abstracted in a method allows subclasses of PathTrie to modify this behavior as needed.
2. Create a PathTrie subclass within ApiBag called `CommandAggregatingPathTrie`. This subclass overrides `attachValueToNode` to combine AnnotatedApi instances together instead of overwriting previously registered values.
3. The actual "combination" logic lives in a class `CommandAggregatingAnnotatedApi extends AnnotatedApi`.
I decided on this approach because it maintains some of the abstractions that seemed important. e.g. PathTrie is saved from needing to know anything about Apis or how to combine them. Combining logic is largely handled by ApiBag, which makes some sense since it's responsible for the registration and storage in the first place. etc.
That said, this was a "best guess" solution, and I'm not especially attached to it. Very open to feedback here.
With this blocker taken care of I'm hoping to split out the Api classes in the next day or two, and then this should be ready to go.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] gerlowskija commented on a change in pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
gerlowskija commented on a change in pull request #81:
URL: https://github.com/apache/solr/pull/81#discussion_r623862243
##########
File path: solr/core/src/java/org/apache/solr/handler/SpecificCollectionAPI.java
##########
@@ -0,0 +1,89 @@
+package org.apache.solr.handler;
+
+import org.apache.solr.api.Command;
+import org.apache.solr.api.EndPoint;
+import org.apache.solr.api.PayloadObj;
+import org.apache.solr.client.solrj.request.beans.BackupCollectionPayload;
+import org.apache.solr.client.solrj.request.beans.ModifyCollectionPayload;
+import org.apache.solr.common.cloud.ZkStateReader;
+import org.apache.solr.common.params.CollectionParams;
+import org.apache.solr.handler.admin.CollectionsHandler;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import static org.apache.solr.client.solrj.SolrRequest.METHOD.DELETE;
+import static org.apache.solr.client.solrj.SolrRequest.METHOD.POST;
+import static org.apache.solr.cloud.api.collections.CollectionHandlingUtils.REQUESTID;
+import static org.apache.solr.common.params.CollectionAdminParams.COLLECTION;
+import static org.apache.solr.common.params.CommonParams.ACTION;
+import static org.apache.solr.common.params.CommonParams.NAME;
+import static org.apache.solr.handler.ClusterAPI.wrapParams;
+import static org.apache.solr.security.PermissionNameProvider.Name.COLL_EDIT_PERM;
+
+
+// TODO This classname sucks - I'm trying to convey that the APIs in this class all operate on a single specific
Review comment:
Hah, yeah no worries. I'm as revolted by the name as it sounds like you are 😛
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] deep8476 commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
deep8476 commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-859636112
Hello
On Fri, Jun 11, 2021, 7:42 PM Jason Gerlowski ***@***.***>
wrote:
> Merged #81 <https://github.com/apache/solr/pull/81> into main.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/solr/pull/81#event-4878251533>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AR75P5ECSJ2YZROWUYB3KF3TSIKS7ANCNFSM43E4YK4Q>
> .
>
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] gerlowskija commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
gerlowskija commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-860611843
> BTW I would have reviewed if you prompted me. It was on the back of my mind already.
Oh, my bad. I thought about pinging you, but didn't want to be a bother (I'd tagged you once already in a recent comment, and didn't want to push it.) It's never too late though - if there's anything you're particularly concerned about lmk and I can take a look.
> In these source files, why did you declare constants ... Referenced only in the command annotation
There's only one usage _right now_, but there's likely to be other places where this string will be used eventually as v2 support progresses. Additional tests might use it, SolrJ will need to use it to make v2 requests at some point, etc. So to the extent I thought about it at all, that was probably my motivation. But I understand your point about the useless indirection being a readability papercut.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dsmiley commented on a change in pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
dsmiley commented on a change in pull request #81:
URL: https://github.com/apache/solr/pull/81#discussion_r623334504
##########
File path: solr/core/src/java/org/apache/solr/handler/SpecificCollectionAPI.java
##########
@@ -0,0 +1,89 @@
+package org.apache.solr.handler;
+
+import org.apache.solr.api.Command;
+import org.apache.solr.api.EndPoint;
+import org.apache.solr.api.PayloadObj;
+import org.apache.solr.client.solrj.request.beans.BackupCollectionPayload;
+import org.apache.solr.client.solrj.request.beans.ModifyCollectionPayload;
+import org.apache.solr.common.cloud.ZkStateReader;
+import org.apache.solr.common.params.CollectionParams;
+import org.apache.solr.handler.admin.CollectionsHandler;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import static org.apache.solr.client.solrj.SolrRequest.METHOD.DELETE;
+import static org.apache.solr.client.solrj.SolrRequest.METHOD.POST;
+import static org.apache.solr.cloud.api.collections.CollectionHandlingUtils.REQUESTID;
+import static org.apache.solr.common.params.CollectionAdminParams.COLLECTION;
+import static org.apache.solr.common.params.CommonParams.ACTION;
+import static org.apache.solr.common.params.CommonParams.NAME;
+import static org.apache.solr.handler.ClusterAPI.wrapParams;
+import static org.apache.solr.security.PermissionNameProvider.Name.COLL_EDIT_PERM;
+
+
+// TODO This classname sucks - I'm trying to convey that the APIs in this class all operate on a single specific
Review comment:
LOL I agree -- my first reaction and I'm glad to see your comment here so I don't need to be delicate about it :-). I have a suggestion in my overall PR comment.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] gerlowskija commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
gerlowskija commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-854319415
I've tentatively pushed a fix for the api-overwriting problem I described in my last comment. The fix I ended up using is as follows:
1. Add a method to PathTrie, `attachValueToNode`, to encapsulate storing an object at a given node. As written in PathTrie this storage uses the same "overwriting" semantics that PathTrie has had up to this point. But having this abstracted in a method allows subclasses of PathTrie to modify this behavior as needed.
2. Create a PathTrie subclass within ApiBag called `CommandAggregatingPathTrie`. This subclass overrides `attachValueToNode` to combine AnnotatedApi instances together instead of overwriting previously registered values.
3. The actual "combination" logic lives in a class `CommandAggregatingAnnotatedApi extends AnnotatedApi`.
I decided on this approach because it maintains some of the abstractions that seemed important. e.g. PathTrie is saved from needing to know anything about Apis or how to combine them. Combining logic is largely handled by ApiBag, which makes some sense since it's responsible for the registration and storage in the first place. etc.
That said, this was a "best guess" solution, and I'm not especially attached to it. Very open to feedback here.
With this blocker taken care of I'm hoping to split out the Api classes in the next day or two, and then this should be ready to go.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] gerlowskija commented on pull request #81: SOLR-15351: Convert /v2/c/ APIs to POJO impl
Posted by GitBox <gi...@apache.org>.
gerlowskija commented on pull request #81:
URL: https://github.com/apache/solr/pull/81#issuecomment-844055719
> If I could be of help, then assign me to do one of the commands and I'll push to your PR.
Thanks for offering David. Any of the remaining APIs would be great if the offer still stands - maybe ADDREPLICAPROPERTY and/or DELETEREPLICAPROPERTY ?
If you don't get to it though, no problem. I'm planning to return and finish this off this weekend in some free-time I've got coming, so it should get done either way.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org