[jira] [Commented] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749394#comment-16749394
]
Lucky Sharma commented on LUCENE-8640:
--
I have incorporated the comments :) please review
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-8640.patch, LUCENE-8640.patch, LUCENE-8640.patch,
> mypatch.patch
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16747380#comment-16747380
]
Lucky Sharma commented on LUCENE-8640:
--
[~dsmiley] Sure, I have updated the same in the new patch and the PR request.
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-8640.patch, LUCENE-8640.patch, LUCENE-8640.patch,
> mypatch.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Updated] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated LUCENE-8640:
-
Attachment: LUCENE-8640.patch
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-8640.patch, LUCENE-8640.patch, LUCENE-8640.patch,
> mypatch.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16747305#comment-16747305
]
Lucky Sharma commented on LUCENE-8640:
--
[~dsmiley][~mkhludnev] I have updated the patch. Please review
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-8640.patch, LUCENE-8640.patch, mypatch.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Updated] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated LUCENE-8640:
-
Attachment: LUCENE-8640.patch
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-8640.patch, LUCENE-8640.patch, mypatch.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746960#comment-16746960
]
Lucky Sharma commented on LUCENE-8640:
--
Sure ,I am already onto it, Will be uploading the patch.
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-8640.patch, mypatch.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Comment Edited] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746059#comment-16746059
]
Lucky Sharma edited comment on LUCENE-8640 at 1/18/19 9:28 AM:
---
Sure, I was unaware of the pattern for the patch file, Will take care of this
in future.
I have updated the patch file name Here also,
was (Author: lsharma3):
Sure, I was unaware of the pattern for the patch file, Will take care of this
in future.
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-8640.patch, mypatch.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Updated] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated LUCENE-8640:
-
Attachment: LUCENE-8640.patch
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: LUCENE-8640.patch, mypatch.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746059#comment-16746059
]
Lucky Sharma commented on LUCENE-8640:
--
Sure, I was unaware of the pattern for the patch file, Will take care of this
in future.
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: mypatch.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Issue Comment Deleted] (SOLR-5211) updating parent as childless makes old children orphans
[ https://issues.apache.org/jira/browse/SOLR-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lucky Sharma updated SOLR-5211: --- Comment: was deleted (was: Yes, that will take 2 calls, I have implemented this with 7.2.1 and 6.6, Patch is attached in this https://issues.apache.org/jira/browse/SOLR-13062.) > updating parent as childless makes old children orphans > --- > > Key: SOLR-5211 > URL: https://issues.apache.org/jira/browse/SOLR-5211 > Project: Solr > Issue Type: Sub-task > Components: update >Affects Versions: 4.5, 6.0 >Reporter: Mikhail Khludnev >Assignee: David Smiley >Priority: Blocker > Fix For: 8.0 > > Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, > SOLR-5211.patch, SOLR-5211.patch > > Time Spent: 3h 40m > Remaining Estimate: 0h > > if I have parent with children in the index, I can send update omitting > children. as a result old children become orphaned. > I suppose separate \_root_ fields makes much trouble. I propose to extend > notion of uniqueKey, and let it spans across blocks that makes updates > unambiguous. > WDYT? Do you like to see a test proves this issue? -- 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-5211) updating parent as childless makes old children orphans
[ https://issues.apache.org/jira/browse/SOLR-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744268#comment-16744268 ] Lucky Sharma commented on SOLR-5211: Yes, that will take 2 calls, I have implemented this with 7.2.1 and 6.6, Patch is attached in this https://issues.apache.org/jira/browse/SOLR-13062. > updating parent as childless makes old children orphans > --- > > Key: SOLR-5211 > URL: https://issues.apache.org/jira/browse/SOLR-5211 > Project: Solr > Issue Type: Sub-task > Components: update >Affects Versions: 4.5, 6.0 >Reporter: Mikhail Khludnev >Assignee: David Smiley >Priority: Blocker > Fix For: 8.0 > > Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, > SOLR-5211.patch, SOLR-5211.patch > > Time Spent: 3h 40m > Remaining Estimate: 0h > > if I have parent with children in the index, I can send update omitting > children. as a result old children become orphaned. > I suppose separate \_root_ fields makes much trouble. I propose to extend > notion of uniqueKey, and let it spans across blocks that makes updates > unambiguous. > WDYT? Do you like to see a test proves this issue? -- 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-5211) updating parent as childless makes old children orphans
[ https://issues.apache.org/jira/browse/SOLR-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744208#comment-16744208 ] Lucky Sharma commented on SOLR-5211: What if we delete the complete block and create the block again and add again via UpdateChainProcessorFactory. In that way, will update only those fields/docs what we want to and put the block back in place > updating parent as childless makes old children orphans > --- > > Key: SOLR-5211 > URL: https://issues.apache.org/jira/browse/SOLR-5211 > Project: Solr > Issue Type: Sub-task > Components: update >Affects Versions: 4.5, 6.0 >Reporter: Mikhail Khludnev >Assignee: David Smiley >Priority: Blocker > Fix For: 8.0 > > Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, > SOLR-5211.patch, SOLR-5211.patch > > Time Spent: 3h 40m > Remaining Estimate: 0h > > if I have parent with children in the index, I can send update omitting > children. as a result old children become orphaned. > I suppose separate \_root_ fields makes much trouble. I propose to extend > notion of uniqueKey, and let it spans across blocks that makes updates > unambiguous. > WDYT? Do you like to see a test proves this issue? -- 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] [Comment Edited] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744039#comment-16744039
]
Lucky Sharma edited comment on LUCENE-8640 at 1/16/19 1:30 PM:
---
yes It passed that test
was (Author: lsharma3):
yes
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: mypatch.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744039#comment-16744039
]
Lucky Sharma commented on LUCENE-8640:
--
yes
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: mypatch.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Updated] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated LUCENE-8640:
-
Attachment: mypatch.patch
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: mypatch.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Updated] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated LUCENE-8640:
-
Attachment: (was: mypatch.patch)
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: mypatch.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Updated] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated LUCENE-8640:
-
Attachment: (was: mypatch.patch)
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: mypatch.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Updated] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated LUCENE-8640:
-
Attachment: mypatch.patch
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: mypatch.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743898#comment-16743898
]
Lucky Sharma commented on LUCENE-8640:
--
Please review the patch for the same
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: mypatch.patch
>
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Updated] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated LUCENE-8640:
-
Attachment: mypatch.patch
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: mypatch.patch
>
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743867#comment-16743867
]
Lucky Sharma commented on LUCENE-8640:
--
[~mkhludnev] will this be count as a valid date -292275055-05-16T16:47:04.192 ?
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743765#comment-16743765
]
Lucky Sharma commented on LUCENE-8640:
--
Sure that will be fine then.
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Comment Edited] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743757#comment-16743757
]
Lucky Sharma edited comment on LUCENE-8640 at 1/16/19 8:44 AM:
---
Should we reject the date completely? or just we can send the calendar which is
matching with the date partially.
In the above example with the valid year 2000 and month 11 with Hour 13
was (Author: lsharma3):
Should we reject the date completely? or just we can send the calendar which is
matching with the date partially.
In the above example with the valid year 2000 and month with Hour 13
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743757#comment-16743757
]
Lucky Sharma commented on LUCENE-8640:
--
Should we reject the date completely? or just we can send the calendar with the
valid year and month with Hour 13
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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] [Comment Edited] (LUCENE-8640) validate delimiters when parsing date ranges
[
https://issues.apache.org/jira/browse/LUCENE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743757#comment-16743757
]
Lucky Sharma edited comment on LUCENE-8640 at 1/16/19 8:44 AM:
---
Should we reject the date completely? or just we can send the calendar which is
matching with the date partially.
In the above example with the valid year 2000 and month with Hour 13
was (Author: lsharma3):
Should we reject the date completely? or just we can send the calendar with the
valid year and month with Hour 13
> validate delimiters when parsing date ranges
>
>
> Key: LUCENE-8640
> URL: https://issues.apache.org/jira/browse/LUCENE-8640
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Mikhail Khludnev
>Priority: Major
>
> {{DateRangePrefixTree.parseCalendar()}} should validate delimiters to rejects
> dates like {{2000-11T13}}
--
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-5211) updating parent as childless makes old children orphans
[ https://issues.apache.org/jira/browse/SOLR-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743593#comment-16743593 ] Lucky Sharma commented on SOLR-5211: [~dsmiley] Hi David, Actually for the backward compatible part, I added one Chain Processor, I raised one Jira ticket with patched. https://issues.apache.org/jira/browse/SOLR-13062 I have discussed it with Mikhail Khludnev, since he suggested its already covered in 8, so I marked my ticket as invalid. The patch is also attached in that Ticket. > updating parent as childless makes old children orphans > --- > > Key: SOLR-5211 > URL: https://issues.apache.org/jira/browse/SOLR-5211 > Project: Solr > Issue Type: Sub-task > Components: update >Affects Versions: 4.5, 6.0 >Reporter: Mikhail Khludnev >Assignee: David Smiley >Priority: Blocker > Fix For: 8.0 > > Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, > SOLR-5211.patch, SOLR-5211.patch > > Time Spent: 3h 40m > Remaining Estimate: 0h > > if I have parent with children in the index, I can send update omitting > children. as a result old children become orphaned. > I suppose separate \_root_ fields makes much trouble. I propose to extend > notion of uniqueKey, and let it spans across blocks that makes updates > unambiguous. > WDYT? Do you like to see a test proves this issue? -- 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] [Resolved] (SOLR-13062) SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding child doc
[
https://issues.apache.org/jira/browse/SOLR-13062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma resolved SOLR-13062.
-
Resolution: Invalid
Fixed in later versions of SOLR8
> SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding
> child doc
>
>
> Key: SOLR-13062
> URL: https://issues.apache.org/jira/browse/SOLR-13062
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Lucky Sharma
>Priority: Minor
> Fix For: 7.2.1, 6.6.3
>
> Attachments: SimpleBlockJoinUpdateProcessor.patch
>
>
> This processor will be responsible for the block join updates/create
> documents in one update request
> This processor will fetch the complete block, update the block where
> updation is needed and push back into the SOLR
> {color:#33}Updation of the complete block based on block
> key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93}
> {color}
> # Parent_ID
> # Block_Level_Key (default is _root_){color:#7d8c93} {color}
> # LevelField which will be 0 for root, 1 for first child, 2 for grand child
> and so on{color:#7d8c93} {color}
> # Primary Field (i.e the ID)
> I/p will be in form of doc wrapper, with parent will hold only the block key
> & option for{color:#7d8c93} update only.{color}{color:#7d8c93} Its child docs
> will contain the which doc in this block you want to update with what
> values.{color}{color:#7d8c93} This is always an atomic update.{color}
--
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-13062) SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding child doc
[
https://issues.apache.org/jira/browse/SOLR-13062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16719663#comment-16719663
]
Lucky Sharma commented on SOLR-13062:
-
[~mkhludnev] what could be the possible release month for solr 8 ?
> SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding
> child doc
>
>
> Key: SOLR-13062
> URL: https://issues.apache.org/jira/browse/SOLR-13062
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Lucky Sharma
>Priority: Minor
> Fix For: 6.6.3, 7.2.1
>
> Attachments: SimpleBlockJoinUpdateProcessor.patch
>
>
> This processor will be responsible for the block join updates/create
> documents in one update request
> This processor will fetch the complete block, update the block where
> updation is needed and push back into the SOLR
> {color:#33}Updation of the complete block based on block
> key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93}
> {color}
> # Parent_ID
> # Block_Level_Key (default is _root_){color:#7d8c93} {color}
> # LevelField which will be 0 for root, 1 for first child, 2 for grand child
> and so on{color:#7d8c93} {color}
> # Primary Field (i.e the ID)
> I/p will be in form of doc wrapper, with parent will hold only the block key
> & option for{color:#7d8c93} update only.{color}{color:#7d8c93} Its child docs
> will contain the which doc in this block you want to update with what
> values.{color}{color:#7d8c93} This is always an atomic update.{color}
--
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-13062) SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding child doc
[
https://issues.apache.org/jira/browse/SOLR-13062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718742#comment-16718742
]
Lucky Sharma commented on SOLR-13062:
-
Oh, Ok. Sure, Will use it as a plugin in my use case. But If you can review it
and provide some valuable feedback It will be much helpful
> SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding
> child doc
>
>
> Key: SOLR-13062
> URL: https://issues.apache.org/jira/browse/SOLR-13062
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Lucky Sharma
>Priority: Minor
> Fix For: 6.6.3, 7.2.1
>
> Attachments: SimpleBlockJoinUpdateProcessor.patch
>
>
> This processor will be responsible for the block join updates/create
> documents in one update request
> This processor will fetch the complete block, update the block where
> updation is needed and push back into the SOLR
> {color:#33}Updation of the complete block based on block
> key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93}
> {color}
> # Parent_ID
> # Block_Level_Key (default is _root_){color:#7d8c93} {color}
> # LevelField which will be 0 for root, 1 for first child, 2 for grand child
> and so on{color:#7d8c93} {color}
> # Primary Field (i.e the ID)
> I/p will be in form of doc wrapper, with parent will hold only the block key
> & option for{color:#7d8c93} update only.{color}{color:#7d8c93} Its child docs
> will contain the which doc in this block you want to update with what
> values.{color}{color:#7d8c93} This is always an atomic update.{color}
--
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-13062) SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding child doc
[
https://issues.apache.org/jira/browse/SOLR-13062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718696#comment-16718696
]
Lucky Sharma commented on SOLR-13062:
-
But That is for version8, this processor will solve the deals in older versions
> SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding
> child doc
>
>
> Key: SOLR-13062
> URL: https://issues.apache.org/jira/browse/SOLR-13062
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Lucky Sharma
>Priority: Minor
> Fix For: 6.6.3, 7.2.1
>
> Attachments: SimpleBlockJoinUpdateProcessor.patch
>
>
> This processor will be responsible for the block join updates/create
> documents in one update request
> This processor will fetch the complete block, update the block where
> updation is needed and push back into the SOLR
> {color:#33}Updation of the complete block based on block
> key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93}
> {color}
> # Parent_ID
> # Block_Level_Key (default is _root_){color:#7d8c93} {color}
> # LevelField which will be 0 for root, 1 for first child, 2 for grand child
> and so on{color:#7d8c93} {color}
> # Primary Field (i.e the ID)
> I/p will be in form of doc wrapper, with parent will hold only the block key
> & option for{color:#7d8c93} update only.{color}{color:#7d8c93} Its child docs
> will contain the which doc in this block you want to update with what
> values.{color}{color:#7d8c93} This is always an atomic update.{color}
--
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] [Updated] (SOLR-13062) SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding child doc
[
https://issues.apache.org/jira/browse/SOLR-13062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated SOLR-13062:
Priority: Minor (was: Major)
Fix Version/s: 6.6.3
7.2.1
> SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding
> child doc
>
>
> Key: SOLR-13062
> URL: https://issues.apache.org/jira/browse/SOLR-13062
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Lucky Sharma
>Priority: Minor
> Fix For: 6.6.3, 7.2.1
>
> Attachments: SimpleBlockJoinUpdateProcessor.patch
>
>
> This processor will be responsible for the block join updates/create
> documents in one update request
> This processor will fetch the complete block, update the block where
> updation is needed and push back into the SOLR
> {color:#33}Updation of the complete block based on block
> key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93}
> {color}
> # Parent_ID
> # Block_Level_Key (default is _root_){color:#7d8c93} {color}
> # LevelField which will be 0 for root, 1 for first child, 2 for grand child
> and so on{color:#7d8c93} {color}
> # Primary Field (i.e the ID)
> I/p will be in form of doc wrapper, with parent will hold only the block key
> & option for{color:#7d8c93} update only.{color}{color:#7d8c93} Its child docs
> will contain the which doc in this block you want to update with what
> values.{color}{color:#7d8c93} This is always an atomic update.{color}
--
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-13062) SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding child doc
[
https://issues.apache.org/jira/browse/SOLR-13062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718593#comment-16718593
]
Lucky Sharma commented on SOLR-13062:
-
[~mkhludnev]
please review
> SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding
> child doc
>
>
> Key: SOLR-13062
> URL: https://issues.apache.org/jira/browse/SOLR-13062
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Lucky Sharma
>Priority: Major
> Attachments: SimpleBlockJoinUpdateProcessor.patch
>
>
> This processor will be responsible for the block join updates/create
> documents in one update request
> This processor will fetch the complete block, update the block where
> updation is needed and push back into the SOLR
> {color:#33}Updation of the complete block based on block
> key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93}
> {color}
> # Parent_ID
> # Block_Level_Key (default is _root_){color:#7d8c93} {color}
> # LevelField which will be 0 for root, 1 for first child, 2 for grand child
> and so on{color:#7d8c93} {color}
> # Primary Field (i.e the ID)
> I/p will be in form of doc wrapper, with parent will hold only the block key
> & option for{color:#7d8c93} update only.{color}{color:#7d8c93} Its child docs
> will contain the which doc in this block you want to update with what
> values.{color}{color:#7d8c93} This is always an atomic update.{color}
--
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] [Updated] (SOLR-13062) SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding child doc
[
https://issues.apache.org/jira/browse/SOLR-13062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated SOLR-13062:
Description:
This processor will be responsible for the block join updates/create documents
in one update request
This processor will fetch the complete block, update the block where updation
is needed and push back into the SOLR
{color:#33}Updation of the complete block based on block
key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93} {color}
# Parent_ID
# Block_Level_Key (default is _root_){color:#7d8c93} {color}
# LevelField which will be 0 for root, 1 for first child, 2 for grand child
and so on{color:#7d8c93} {color}
# Primary Field (i.e the ID)
I/p will be in form of doc wrapper, with parent will hold only the block key &
option for{color:#7d8c93} update only.{color}{color:#7d8c93} Its child docs
will contain the which doc in this block you want to update with what
values.{color}{color:#7d8c93} This is always an atomic update.{color}
was:
This processor will be responsible for the block join updates/create documents
in one update request
{color:#33}Updation of the complete block based on block
key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93} {color}
# Parent_ID
# Block_Level_Key (default is _root_){color:#7d8c93} {color}
# LevelField which will be 0 for root, 1 for first child, 2 for grand child
and so on{color:#7d8c93} {color}
# Primary Field (i.e the ID)
I/p will be in form of doc wrapper, with parent will hold only the block key &
option for{color:#7d8c93} update only.{color}{color:#7d8c93} Its child docs
will contain the which doc in this block you want to update with what
values.{color}{color:#7d8c93} This is always an atomic update.{color}
> SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding
> child doc
>
>
> Key: SOLR-13062
> URL: https://issues.apache.org/jira/browse/SOLR-13062
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Lucky Sharma
>Priority: Major
> Attachments: SimpleBlockJoinUpdateProcessor.patch
>
>
> This processor will be responsible for the block join updates/create
> documents in one update request
> This processor will fetch the complete block, update the block where
> updation is needed and push back into the SOLR
> {color:#33}Updation of the complete block based on block
> key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93}
> {color}
> # Parent_ID
> # Block_Level_Key (default is _root_){color:#7d8c93} {color}
> # LevelField which will be 0 for root, 1 for first child, 2 for grand child
> and so on{color:#7d8c93} {color}
> # Primary Field (i.e the ID)
> I/p will be in form of doc wrapper, with parent will hold only the block key
> & option for{color:#7d8c93} update only.{color}{color:#7d8c93} Its child docs
> will contain the which doc in this block you want to update with what
> values.{color}{color:#7d8c93} This is always an atomic update.{color}
--
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] [Updated] (SOLR-13062) SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding child doc
[
https://issues.apache.org/jira/browse/SOLR-13062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated SOLR-13062:
Description:
This processor will be responsible for the block join updates/create documents
in one update request
{color:#33}Updation of the complete block based on block
key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93} {color}
# Parent_ID
# Block_Level_Key (default is _root_){color:#7d8c93} {color}
# LevelField which will be 0 for root, 1 for first child, 2 for grand child
and so on{color:#7d8c93} {color}
# Primary Field (i.e the ID)
I/p will be in form of doc wrapper, with parent will hold only the block key &
option for{color:#7d8c93} update only.{color}{color:#7d8c93} Its child docs
will contain the which doc in this block you want to update with what
values.{color}{color:#7d8c93} This is always an atomic update.{color}
was:
Since, We are unable to to any update on block documents,
This processor will be responsible for the block join updates/create documents
{color:#33}{color:#7d8c93}Updation of the complete block based on block
key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93}
{color}{color}
# {color:#33}{color:#7d8c93}Parent_ID{color}{color}
# {color:#33}{color:#7d8c93} Block_Level_Key (default is
_root_){color}{color:#7d8c93} {color}{color}
# {color:#33}{color:#7d8c93} LevelField which will be 0 for root, 1 for
first child, 2 for grand child and so on{color}{color:#7d8c93} {color}{color}
# {color:#33}{color:#7d8c93}Primary Field (i.e the ID){color} {color}
{color:#33}{color:#7d8c93}I/p will be in form of doc wrapper, with parent
will hold only the block key & option for{color}{color:#7d8c93} update
only.{color}{color:#7d8c93} Its child docs will contain the which doc in this
block you want to update with what values.{color}{color:#7d8c93} This is always
an atomic update.{color}{color}
> SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding
> child doc
>
>
> Key: SOLR-13062
> URL: https://issues.apache.org/jira/browse/SOLR-13062
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Lucky Sharma
>Priority: Major
> Attachments: SimpleBlockJoinUpdateProcessor.patch
>
>
> This processor will be responsible for the block join updates/create
> documents in one update request
>
> {color:#33}Updation of the complete block based on block
> key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93}
> {color}
> # Parent_ID
> # Block_Level_Key (default is _root_){color:#7d8c93} {color}
> # LevelField which will be 0 for root, 1 for first child, 2 for grand child
> and so on{color:#7d8c93} {color}
> # Primary Field (i.e the ID)
>
> I/p will be in form of doc wrapper, with parent will hold only the block key
> & option for{color:#7d8c93} update only.{color}{color:#7d8c93} Its child docs
> will contain the which doc in this block you want to update with what
> values.{color}{color:#7d8c93} This is always an atomic update.{color}
--
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] [Updated] (SOLR-13062) SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding child doc
[
https://issues.apache.org/jira/browse/SOLR-13062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated SOLR-13062:
Description:
Since, We are unable to to any update on block documents,
This processor will be responsible for the block join updates/create documents
{color:#33}{color:#7d8c93}Updation of the complete block based on block
key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93}
{color}{color}
# {color:#33}{color:#7d8c93}Parent_ID{color}{color}
# {color:#33}{color:#7d8c93} Block_Level_Key (default is
_root_){color}{color:#7d8c93} {color}{color}
# {color:#33}{color:#7d8c93} LevelField which will be 0 for root, 1 for
first child, 2 for grand child and so on{color}{color:#7d8c93} {color}{color}
# {color:#33}{color:#7d8c93}Primary Field (i.e the ID){color} {color}
{color:#33}{color:#7d8c93}I/p will be in form of doc wrapper, with parent
will hold only the block key & option for{color}{color:#7d8c93} update
only.{color}{color:#7d8c93} Its child docs will contain the which doc in this
block you want to update with what values.{color}{color:#7d8c93} This is always
an atomic update.{color}{color}
was:
Since, We are unable to to any update on block documents,
This processor will be responsible for the block join updates/create documents
{color:#7d8c93}Updation of the complete block based on block key,
{color}{color:#7d8c93} Document must contain:
{color}{color:#7d8c93} 1. Parent_ID
{color}{color:#7d8c93} 2. Block_Level_Key (default is _root_)
{color}{color:#7d8c93} 3. LevelField which will be 0 for root, 1 for first
child, 2 for grand child and so on
{color}{color:#7d8c93} 4. primary Field (i.e the ID)
{color}{color:#7d8c93}
{color}{color:#7d8c93} I/p will be in form of doc wrapper, with parent will
hold only the block key & option for
{color}{color:#7d8c93} update only.
{color}{color:#7d8c93} Its child docs will contain the which doc in this block
you want to update with what values.
{color}{color:#7d8c93} This is always an atomic update.{color}
> SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding
> child doc
>
>
> Key: SOLR-13062
> URL: https://issues.apache.org/jira/browse/SOLR-13062
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Lucky Sharma
>Priority: Major
> Attachments: SimpleBlockJoinUpdateProcessor.patch
>
>
> Since, We are unable to to any update on block documents,
> This processor will be responsible for the block join updates/create documents
>
> {color:#33}{color:#7d8c93}Updation of the complete block based on block
> key,{color}{color:#7d8c93} Document must contain:{color}{color:#7d8c93}
> {color}{color}
> # {color:#33}{color:#7d8c93}Parent_ID{color}{color}
> # {color:#33}{color:#7d8c93} Block_Level_Key (default is
> _root_){color}{color:#7d8c93} {color}{color}
> # {color:#33}{color:#7d8c93} LevelField which will be 0 for root, 1 for
> first child, 2 for grand child and so on{color}{color:#7d8c93} {color}{color}
> # {color:#33}{color:#7d8c93}Primary Field (i.e the ID){color} {color}
> {color:#33}{color:#7d8c93}I/p will be in form of doc wrapper, with parent
> will hold only the block key & option for{color}{color:#7d8c93} update
> only.{color}{color:#7d8c93} Its child docs will contain the which doc in this
> block you want to update with what values.{color}{color:#7d8c93} This is
> always an atomic update.{color}{color}
--
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] [Updated] (SOLR-13062) SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding child doc
[
https://issues.apache.org/jira/browse/SOLR-13062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucky Sharma updated SOLR-13062:
Summary: SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and
adding child doc (was: UpdateProcessorFactory for Atomic update and adding
child doc )
> SimpleBlockJoinUpdateRequestProcessorFactory for Atomic update and adding
> child doc
>
>
> Key: SOLR-13062
> URL: https://issues.apache.org/jira/browse/SOLR-13062
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Reporter: Lucky Sharma
>Priority: Major
> Attachments: SimpleBlockJoinUpdateProcessor.patch
>
>
> Since, We are unable to to any update on block documents,
> This processor will be responsible for the block join updates/create documents
>
> {color:#7d8c93}Updation of the complete block based on block key,
> {color}{color:#7d8c93} Document must contain:
> {color}{color:#7d8c93} 1. Parent_ID
> {color}{color:#7d8c93} 2. Block_Level_Key (default is _root_)
> {color}{color:#7d8c93} 3. LevelField which will be 0 for root, 1 for first
> child, 2 for grand child and so on
> {color}{color:#7d8c93} 4. primary Field (i.e the ID)
> {color}{color:#7d8c93}
> {color}{color:#7d8c93} I/p will be in form of doc wrapper, with parent will
> hold only the block key & option for
> {color}{color:#7d8c93} update only.
> {color}{color:#7d8c93} Its child docs will contain the which doc in this
> block you want to update with what values.
> {color}{color:#7d8c93} This is always an atomic update.{color}
--
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] [Created] (SOLR-13062) UpdateProcessorFactory for Atomic update and adding child doc
Lucky Sharma created SOLR-13062:
---
Summary: UpdateProcessorFactory for Atomic update and adding child
doc
Key: SOLR-13062
URL: https://issues.apache.org/jira/browse/SOLR-13062
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: UpdateRequestProcessors
Reporter: Lucky Sharma
Attachments: SimpleBlockJoinUpdateProcessor.patch
Since, We are unable to to any update on block documents,
This processor will be responsible for the block join updates/create documents
{color:#7d8c93}Updation of the complete block based on block key,
{color}{color:#7d8c93} Document must contain:
{color}{color:#7d8c93} 1. Parent_ID
{color}{color:#7d8c93} 2. Block_Level_Key (default is _root_)
{color}{color:#7d8c93} 3. LevelField which will be 0 for root, 1 for first
child, 2 for grand child and so on
{color}{color:#7d8c93} 4. primary Field (i.e the ID)
{color}{color:#7d8c93}
{color}{color:#7d8c93} I/p will be in form of doc wrapper, with parent will
hold only the block key & option for
{color}{color:#7d8c93} update only.
{color}{color:#7d8c93} Its child docs will contain the which doc in this block
you want to update with what values.
{color}{color:#7d8c93} This is always an atomic update.{color}
--
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] [Comment Edited] (SOLR-5211) updating parent as childless makes old children orphans
[ https://issues.apache.org/jira/browse/SOLR-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708159#comment-16708159 ] Lucky Sharma edited comment on SOLR-5211 at 12/4/18 5:20 AM: - Hi All, I need one recommendation, To solve the same parent-child update problem, in versions 6 & 7, we have written our own UpdateProcessors, Will that be a definite approach. If yes I would be much happier if someone can review my code , and provide valuable feedback for that fix was (Author: lsharma3): Hi All, I need one recommendation, To solve the same parent-child update problem, in versions 6 & 7, we have written our own UpdateProcessors, Will that be a definite approach. If yes I would be much happier if someone can review the same, and provide valuable feedback for that fix > updating parent as childless makes old children orphans > --- > > Key: SOLR-5211 > URL: https://issues.apache.org/jira/browse/SOLR-5211 > Project: Solr > Issue Type: Sub-task > Components: update >Affects Versions: 4.5, 6.0 >Reporter: Mikhail Khludnev >Assignee: David Smiley >Priority: Blocker > Fix For: master (8.0) > > Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, > SOLR-5211.patch, SOLR-5211.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > if I have parent with children in the index, I can send update omitting > children. as a result old children become orphaned. > I suppose separate \_root_ fields makes much trouble. I propose to extend > notion of uniqueKey, and let it spans across blocks that makes updates > unambiguous. > WDYT? Do you like to see a test proves this issue? -- 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-5211) updating parent as childless makes old children orphans
[ https://issues.apache.org/jira/browse/SOLR-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708159#comment-16708159 ] Lucky Sharma commented on SOLR-5211: Hi All, I need one recoomendation, To solve the same parent child update problem, in versions 6 & 7, we have written our own UpdateProcessors, Will that be a definate approach. If yes I would be much happier if some one can review the same, and provide valuable feedback for that fix > updating parent as childless makes old children orphans > --- > > Key: SOLR-5211 > URL: https://issues.apache.org/jira/browse/SOLR-5211 > Project: Solr > Issue Type: Sub-task > Components: update >Affects Versions: 4.5, 6.0 >Reporter: Mikhail Khludnev >Assignee: David Smiley >Priority: Blocker > Fix For: master (8.0) > > Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, > SOLR-5211.patch, SOLR-5211.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > if I have parent with children in the index, I can send update omitting > children. as a result old children become orphaned. > I suppose separate \_root_ fields makes much trouble. I propose to extend > notion of uniqueKey, and let it spans across blocks that makes updates > unambiguous. > WDYT? Do you like to see a test proves this issue? -- 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] [Comment Edited] (SOLR-5211) updating parent as childless makes old children orphans
[ https://issues.apache.org/jira/browse/SOLR-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708159#comment-16708159 ] Lucky Sharma edited comment on SOLR-5211 at 12/4/18 4:04 AM: - Hi All, I need one recommendation, To solve the same parent-child update problem, in versions 6 & 7, we have written our own UpdateProcessors, Will that be a definite approach. If yes I would be much happier if someone can review the same, and provide valuable feedback for that fix was (Author: lsharma3): Hi All, I need one recoomendation, To solve the same parent child update problem, in versions 6 & 7, we have written our own UpdateProcessors, Will that be a definate approach. If yes I would be much happier if some one can review the same, and provide valuable feedback for that fix > updating parent as childless makes old children orphans > --- > > Key: SOLR-5211 > URL: https://issues.apache.org/jira/browse/SOLR-5211 > Project: Solr > Issue Type: Sub-task > Components: update >Affects Versions: 4.5, 6.0 >Reporter: Mikhail Khludnev >Assignee: David Smiley >Priority: Blocker > Fix For: master (8.0) > > Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, > SOLR-5211.patch, SOLR-5211.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > if I have parent with children in the index, I can send update omitting > children. as a result old children become orphaned. > I suppose separate \_root_ fields makes much trouble. I propose to extend > notion of uniqueKey, and let it spans across blocks that makes updates > unambiguous. > WDYT? Do you like to see a test proves this issue? -- 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
