[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16508171#comment-16508171 ] ASF subversion and git services commented on SOLR-12361: Commit 7744162905e3d9c613262c23c242d238596d058f in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7744162 ] SOLR-12361: Allow nested child documents to be in field values of a SolrInputDocument. * AddUpdateCommand and it's relationship with DirectUpdateHandler2 was reworked substantially. Fixes #385 (cherry picked from commit 8095139) > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch, SOLR-12361.patch, > SOLR-12361.patch > > Time Spent: 10h 10m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16508160#comment-16508160 ] ASF subversion and git services commented on SOLR-12361: Commit 8095139da3598e9f76c8d960855535553b753ee9 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8095139 ] SOLR-12361: Allow nested child documents to be in field values of a SolrInputDocument. * AddUpdateCommand and it's relationship with DirectUpdateHandler2 was reworked substantially. Fixes #385 > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch, SOLR-12361.patch, > SOLR-12361.patch > > Time Spent: 10h > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16507255#comment-16507255 ] mosh commented on SOLR-12361: - {quote}What do you think mosh? How should I refer to you in CHANGES.txt? {quote} I like it, this patch looks ready. You can simply refer to me as MosheBla. > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch, SOLR-12361.patch, > SOLR-12361.patch > > Time Spent: 10h > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16506274#comment-16506274 ] David Smiley commented on SOLR-12361: - New patch: * removed overloaded getLuceneDocument(isInplaceUpdate) since we can simply call IsInPlaceUpdate() internally * Added "ignoreNestedDocs" flag to DocumentBuilder.toDocument() to toggle wether it throws an exception or ignores them. Further, AddUpdateCommand.getLuceneDocsIfNested() now checks this early and returns null instead of throwing an exception later in this method. I left the document equality issue for another time, commenting on SOLR-5265: https://issues.apache.org/jira/browse/SOLR-5265?focusedCommentId=16506268&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16506268 I think this is ready. The tests pass, and precommit is running now. What do you think [~moshebla]? How should I refer to you in CHANGES.txt? > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch, SOLR-12361.patch, > SOLR-12361.patch > > Time Spent: 10h > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16505685#comment-16505685 ] David Smiley commented on SOLR-12361: - I took your PR and ran with it a bit further; patch attached. I had a stupid bug that took some time to debug so I wasn't ready till now. I'm running tests but so far so good. * Moved/added javadocs to SolrDocumentBase instead of subclass impls RE child docs. I added a bit more info to them and made getChildDocumentCount deprecated. * IngoreLargeDocumentProcessorFactory: ensured the value side of estimate(map) uses the recursive estimate() instead of the non-recursive primitiveEstimate(). AddUpdateCommand: * pending nocommit that getLuceneDocument(inPlaceUpdate) is in fact always == isInPlaceUpdate() so this parameter is not needed and I think we can get rid of this overloaded variant. * rename: getLuceneDocsIfNested (to balance with getLuceneDocument). Added javadocs. * this method now returns Iterable and null if it turns out there is no nesting. This solves some awkwardness in exposing SolrInputDocument type to the UpdateHandler which we don't want. * rename: recUnwrap... to flatten * moved isUsableForChildDocs check to getLuceneDocsIfNested where (to me) it seems nicer) DirectUpdateHandler2: * updateDocOrDocValues now has a simpler method contract; it's caller doesn't need to pass the "updateTerm" as it did originally, and improved from the last patch we return void not the idTerm. doNormalUpdate had "cmd.updateTerm" (signature dedupe) logic that needed the idTerm & updateTerm which was why earlier I thought to return it but after some examination I think it's better if this logic was absorbed into updateDocOrDocValues. I inlined updateDocument() into updateDocOrDocValues -- ultimately trying to make the code path and scope of idTerm/updateTerm more clear and I'm pretty happy with it. Note "inline" is a verb used in coding (and can be found in IDE's for example); you earlier mistook my suggestion as a suggestion to rename a method. Looking again at SolrTestCaseJ4.compareSolrInputDocument... maybe this logic ought to go on SolrInputDocument or better SolrDocumentBase as equals()? If it were moved there, you wouldn't have even needed to make the change you did, and thus it'd be simpler and more obvious -- why should one have to know SolrTestCaseJ4.compareSolrInputDocument exists. Heck, I can argue that SolrDocumentBase doesn't meet the contract of the Map it implements since a Map's equals() demands it actually works! (hashcode too) > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 10h > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16499819#comment-16499819 ] Cao Manh Dat commented on SOLR-12361: - [~dsmiley] In {{fastEstimate(map)}} and {{fastEstimate(collection)}} we only count its element if it is a primitive object (we do not go further here). {quote}line 115 could be changed to loop on the SolrInputFields instead of the field names to avoid doing an internal hashmap lookup on all field names. {quote} +1 for this one. With the change in pull request, we can change {{fastEstimate}} to {{estimate}} and merge all the duplications. > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 9h 40m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16496048#comment-16496048 ] David Smiley commented on SOLR-12361: - [~caomanhdat] can you please review the changes to IgnoreLargeDocumentProcessorFactory that mosh changed in PR 385? (note it includes more tests). I have and it looks good though I admit I'm confused by this URP as to when exactly it's doing a "primitiveEstimate" vs doing a "fastEstimate" (that isn't necessarily primitive). Two of the instanceof dispatches look similar (fastEstimate(obj) and inside the loop of fastEstimate(map ). Hey BTW line 115 could be changed to loop on the SolrInputFields instead of the field names to avoid doing an internal hashmap lookup on all field names. > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 5h 10m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16492288#comment-16492288 ] mosh commented on SOLR-12361: - added a new WIP pull request [#385|https://github.com/apache/lucene-solr/pull/385] > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 2h > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488963#comment-16488963 ] David Smiley commented on SOLR-12361: - BTW another thing I like about the approach of treating child documents as field values is that it could make it easier / more natural to _return_ child documents in all/most of our response formats (except perhaps CSV) since they are attached to the field name just as will be allowed on the way in. If we instead go with the path of merely turning the List child into a Map with String semantic key (#2 path), we would then need to consider how each response format deals with semantic children (how this looks in XML, JSON, Ruby, ...), which would certainly add code/complexity rather than the unifying principle of using field names. > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488935#comment-16488935 ] David Smiley commented on SOLR-12361: - bq. Do you propose we deprecate _childDocuments for the time being, leave it as is, while implementing child docs as values? Later on(Solr 8.0) the _childDocuments will be removed? Yes. (BTW I recommend sticking with using master branch for patch development / WIP; it shouldn't be an issue) bq. Plus, would we have to enforce that no childDocument is inserted inside the childDocuments key annonymous childDocuments were inserted to the current doc? That was my "XOR" posed as a question... I think we shouldn't bother to complicate ourselves with preventing it; so let it be possible. In practice, I expect users to do one or the other. RE DocumentBuilder: Maybe nevermind my thoughts on changing that. But I do think the changes to remove cmd.isBlock are worthwhile as it helps us remove `org.apache.solr.common.SolrDocumentBase#hasChildDocuments` > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488462#comment-16488462 ] mosh commented on SOLR-12361: - {quote}Also, I wonder if we even need to directly "flatten" the tree to a List after all? Consider your change to DocumentBuilder; maybe it should just operate recursively? Granted DocumentBuilder would then need to return a List but whatever.{quote} This could be changed if it is deemed as a better approach. > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 50m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488429#comment-16488429 ] mosh commented on SOLR-12361: - {quote}Lets say that docs can have semantic child relations (named child relations), *OR* (XOR?) they can have anonymous ones – what we have today. {quote} Just to make sure we're on the same page [~dsmiley]. Do you propose we deprecate _childDocuments for the time being, leave it as is, while implementing child docs as values? Later on(Solr 8.0) the _childDocuments will be removed? > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 50m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488401#comment-16488401 ] David Smiley commented on SOLR-12361: - I looked closer at what it would take to remove the direct flattening. AddUpdateCommand would no longer implement Iterable. DirectUpdateHandler2.allowDuplicateUpdate currently grabs this iterable and passes to Lucene IndexWriter. I think it could instead grab a List from the command, after which it could then check the size for > 1 and add one document or the set of them atomically (no need for cmd.isBlock). Maybe I'll look at this more tomorrow. So this could remove the isBlock call which is potentially expensive'ish. We could even do this and leave DocumentBuilder alone; keep the flatten. Shrug; eh; debatable... > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 50m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488384#comment-16488384 ] David Smiley commented on SOLR-12361: - I mostly finished reviewing #382 (removal of \_childDocuments) but I ought to look a bit more; plus I need to look at your #2 path. As I was looking at #382, I kept thinking of back-compat ramifications, and then an epiphany hit me: Lets say that docs can have semantic child relations (named child relations), *OR* (XOR?) they can have anonymous ones -- what we have today. The latter (anonymous), lets say we retain this for now in 7x (keep \_childDocuments impl) but come 8.0 we remove it. For now just leave it and we deal with child docs potentially in both places. In this scheme, doc.getChildDocuments only returns anonymous children (impl doesn't change). We can't change the name unfortunately but we can add javadocs that scream this point and potentially mark itself deprecated. With this path, the main thing to concern ourselves with right now is simply supporting SolrInputDocument as field values and not worrying about disturbing back-compat. This means we also needn't worry about, say, your change to ClientUtils.writeXML since child docs can come from either place and it's okay (no duplication of same docs to worry about). Also, I wonder if we even need to directly "flatten" the tree to a List after all? Consider your change to DocumentBuilder; maybe it should just operate recursively? Granted DocumentBuilder would then need to return a List but whatever. > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 50m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487477#comment-16487477 ] mosh commented on SOLR-12361: - I have just uploaded a pull request incorporating child documents as values inside SolrInputDocument. Perhaps you could check it out and so we can discuss which option is better suited out of the two: 1. The pull request: [GitHub Pull Request #382|https://github.com/apache/lucene-solr/pull/382] 2. _childDocuments as a Map: {quote}Perhaps changing the _childDocuments to Map {quote} > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16483978#comment-16483978 ] David Smiley commented on SOLR-12361: - +1 to that > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 20m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16483513#comment-16483513 ] mosh commented on SOLR-12361: - [~dsmiley] Perhaps changing the _childDocuments to Map (maybe a name change should be made) could solve our problem gracefully? > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 20m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482200#comment-16482200 ] mosh commented on SOLR-12361: - bq. Oh yeah; the multi-valued question makes this solution path more complicated because it needs to duplicate similar logic that exists for plain field values. add(key,Object) is ugly. Ugh. Could you please try the approach of adding SolrInputDocuments as if they were fields values? I have started doing this in another branch, this might be the better way to go, but it will require a lot of adjusting of current unit tests. Hopefully I'll have a WIP pull request up by tomorrow. > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 20m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479953#comment-16479953 ] Lucene/Solr QA commented on SOLR-12361: --- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | || || || || {color:brown} master Compile Tests {color} || | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 4s{color} | {color:green} master passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 6s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 6s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Release audit (RAT) {color} | {color:green} 2m 29s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Check forbidden APIs {color} | {color:green} 2m 17s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Validate source patterns {color} | {color:green} 2m 17s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red}192m 58s{color} | {color:red} core in the patch failed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 6m 41s{color} | {color:red} solrj in the patch failed. {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 45s{color} | {color:green} test-framework in the patch passed. {color} | | {color:black}{color} | {color:black} {color} | {color:black}210m 5s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | solr.search.join.TestCloudNestedDocsSort | | | solr.cloud.MoveReplicaHDFSTest | | | solr.common.util.TestJavaBinCodec | \\ \\ || Subsystem || Report/Notes || | JIRA Issue | SOLR-12361 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12923887/SOLR-12361.patch | | Optional Tests | compile javac unit ratsources checkforbiddenapis validatesourcepatterns | | uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | ant | | Personality | /home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh | | git revision | master / 7bb3e5c | | ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 | | Default Java | 1.8.0_172 | | unit | https://builds.apache.org/job/PreCommit-SOLR-Build/97/artifact/out/patch-unit-solr_core.txt | | unit | https://builds.apache.org/job/PreCommit-SOLR-Build/97/artifact/out/patch-unit-solr_solrj.txt | | Test Results | https://builds.apache.org/job/PreCommit-SOLR-Build/97/testReport/ | | modules | C: solr/core solr/solrj solr/test-framework U: solr | | Console output | https://builds.apache.org/job/PreCommit-SOLR-Build/97/console | | Powered by | Apache Yetus 0.7.0 http://yetus.apache.org | This message was automatically generated. > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 20m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479166#comment-16479166 ] David Smiley commented on SOLR-12361: - Oh yeah; the multi-valued question makes this solution path more complicated because it needs to duplicate similar logic that exists for plain field values. add(key,Object) is ugly. Ugh. Could you please try the approach of adding SolrInputDocuments as if they were fields values? > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch, SOLR-12361.patch > > Time Spent: 20m > Remaining Estimate: 0h > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477455#comment-16477455 ] Lucene/Solr QA commented on SOLR-12361: --- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | || || || || {color:brown} master Compile Tests {color} || | {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 59s{color} | {color:green} master passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 18s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m 18s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Release audit (RAT) {color} | {color:green} 5m 8s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Check forbidden APIs {color} | {color:green} 4m 43s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Validate source patterns {color} | {color:green} 4m 43s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:red}-1{color} | {color:red} unit {color} | {color:red}120m 14s{color} | {color:red} core in the patch failed. {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 12m 43s{color} | {color:green} solrj in the patch passed. {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 49s{color} | {color:green} test-framework in the patch passed. {color} | | {color:black}{color} | {color:black} {color} | {color:black}154m 15s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster | | | solr.cloud.autoscaling.SearchRateTriggerIntegrationTest | | | solr.cloud.autoscaling.sim.TestLargeCluster | | | solr.cloud.autoscaling.SearchRateTriggerTest | \\ \\ || Subsystem || Report/Notes || | JIRA Issue | SOLR-12361 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12923652/SOLR-12361.patch | | Optional Tests | compile javac unit ratsources checkforbiddenapis validatesourcepatterns | | uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | ant | | Personality | /home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh | | git revision | master / b3894d7 | | ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 | | Default Java | 1.8.0_172 | | unit | https://builds.apache.org/job/PreCommit-SOLR-Build/94/artifact/out/patch-unit-solr_core.txt | | Test Results | https://builds.apache.org/job/PreCommit-SOLR-Build/94/testReport/ | | modules | C: solr/core solr/solrj solr/test-framework U: solr | | Console output | https://builds.apache.org/job/PreCommit-SOLR-Build/94/console | | Powered by | Apache Yetus 0.7.0 http://yetus.apache.org | This message was automatically generated. > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > Attachments: SOLR-12361.patch > > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12361) Change _childDocuments to Map
[ https://issues.apache.org/jira/browse/SOLR-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476952#comment-16476952 ] mosh commented on SOLR-12361: - quoting [~dsmiley] {quote}One other variation on an approach is to keep the _childDocuments member of SolrInputDocument but have it be a Map> to capture the relationship name. {quote} This would make all children as multiValued fields. How do you propose we store whether the fields was an array or a single value document when it was entered? Perhaps we should have the _childDocuments be a Map, having the values either be a SolrInputDocument or a Collection. > Change _childDocuments to Map > - > > Key: SOLR-12361 > URL: https://issues.apache.org/jira/browse/SOLR-12361 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > > During the discussion on SOLR-12298, there was a proposal to change > _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship > between the parent and its child documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org