[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] [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
[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=16698466#comment-16698466 ] mosh edited comment on SOLR-5211 at 11/26/18 5:31 AM: -- I uploaded another patch in which RootFieldTest uses schema.xml and schema15.xml(instead of schema11), since the "name" field, which is used throughout this particular test suite, is not defined in schema11.xml. was (Author: moshebla): I uploaded another patch in which RootFieldTest uses schema.xml and schema15.xml(instead of schema11), since the "name" field is not defined in schema11.xml. > 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=16694222#comment-16694222
]
David Smiley edited comment on SOLR-5211 at 11/21/18 4:33 AM:
--
Moshe and I iterated a bit on the linked PR and I think it's ready. Proposed
CHANGES.txt as follows under Improvements:
{noformat}
If _root_ is defined in the schema, it is now always populated automatically.
This allows
documents with children to be updated with a document that does not have
children, whereas
before it would break block-join queries. If you don't use nested documents
then _root_ can
be removed as always.
{noformat}
I plan to commit tomorrow to master only. I'll have my laptop with me over
Thanksgiving holidays in case there are issues.
was (Author: dsmiley):
Moshe and I iterated a bit on the linked PR and I think it's ready. Proposed
CHANGES.txt as follows under Improvements:
{noformat}
If _root_ is defined in the schema, it is now always populated automatically.
This allows documents with children to be updated with a document that does not
have children, whereas before it would break block-join queries. If you don't
use nested documents then _root_ can be removed as always.
{noformat}
I plan to commit tomorrow to master only. I'll have my laptop with me over
Thanksgiving holidays in case there are issues.
> 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
>
> Time Spent: 3h
> 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=16690359#comment-16690359 ] Dr Oleg Savrasov edited comment on SOLR-5211 at 11/17/18 3:57 AM: -- [~moshebla], don't have time these days, sorry. I'll try to return to the feature in December-January if it's not too late. was (Author: osavrasov): [~moshebla], don't have time these days, sorry. > 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 > > > 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=16496774#comment-16496774
]
Mikhail Khludnev edited comment on SOLR-5211 at 5/31/18 4:08 PM:
-
This what we discussed at Vegas, [~hossman]. Let's treat all docs (even
childfree) parents. Here are pros, and cons:
(+) mixing parents and childfree (not yet in tests)
(+) overwriting childfree by parent (in tests)
(-) for those who run childfree-only index its waste index space for storing
useless {{\_root_}} column, as a workaround they can enable {{}} (I'm not happy about this name).
* atomic updates for parents is not there but just possible
I'd like to tweak the tests a little. Meanwhile, the questions are:
- Are we going this way?
- what release strategy is worth to take? eg make {{ParentAlwaysDUH2}} optional
in 7.4. but default in 8.0 or turn it by default right now
was (Author: mkhludnev):
This what we discussed at Vegas, [~hossman]. Let's treat all docs (even
childfree) parents. Here are pros, and cons:
(+) mixing parents and childfree (not yet in tests)
(+) overwriting childfree by parent (in tests)
(-) for those who run childfree-only index its waste index space for storing
useless {{\_root_}} column, as a workaround they can enable {{ }} (I'm not happy about this name).
* atomic updates for parents is not there but just possible
I'd like to tweak the tests a little. Meanwhile, the questions are:
- Are we going this way?
- what release strategy is worth to take? eg make {{ParentAlwaysDUH2}} optional
in 7.4. but default in 8.0 or turn it by default right now
> 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: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-5211.patch
>
>
> 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=15041236#comment-15041236
]
Mikhail Khludnev edited comment on SOLR-5211 at 12/4/15 8:10 AM:
-
I want to emphasize two things: multilevel nesting is out of scope so far, just
because we can't deal with the simplest single level parent/child case yet; I
don't think we can afford to complicate update flow, ie. add {{deleteBy\*}} or
check are there children (btw, they can be commited yet).
We need to come up with universal routine which can handle all cases below via
the single API entry point [IW.updateDocuments(delTerm,
docs)|https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java#L1299]
or establish the new one:
- add with/without children
- update (overwrite) with/without children
- let to omit uniquKey in schema, it this case it won't overwrite itself
just to remind, now it work as {{delTerm=$uniqueKey:get($uniqueKey)}} for
childless, and {{delTerm=\_root_:get($uniqueKey)}}. here is the problem.
IMHO, -if we just allow $uniqueKey to span across a whole block (q=id:33
returns a block of several docs), it would be nobrainer, which solves
everything.- Let's just *always* copy $uniqueKey to \_root_, span it to all
children and use \_root_:get($uniqueKey) as a delete term?!!
What I'm missing?
was (Author: mkhludnev):
I want to emphasize two things: multilevel nesting is out of scope so far, just
because we can't deal with the simplest single level parent/child case yet; I
don't think we can afford to complicate update flow, ie. add {{deleteBy\*}} or
check are there children (btw, they can be commited yet).
We need to come up with universal routine which can handle all cases below via
the single API entry point [IW.updateDocuments(delTerm,
docs)|https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java#L1299]
or establish the new one:
- add with/without children
- update (overwrite) with/without children
- let to omit uniquKey in schema, it this case it won't overwrite itself
just to remind, now it work as {{delTerm=$uniqueKey:get($uniqueKey)}} for
childless, and {{delTerm=\_root_:get($uniqueKey)}}. here is the problem.
IMHO, -if we just allow $uniqueKey to span across a whole block (q=id:33
returns a block of several docs), it would be nobrainer, which solves
everything.- Let's just *always* copy $uniqueKey to \_root_ spans it to all
children and use \_root_:get($uniqueKey) as a delete term,
What I'm missing?
> 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, Trunk
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Fix For: Trunk, 5.5
>
>
> 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
(v6.3.4#6332)
-
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=15041236#comment-15041236
]
Mikhail Khludnev edited comment on SOLR-5211 at 12/4/15 8:09 AM:
-
I want to emphasize two things: multilevel nesting is out of scope so far, just
because we can't deal with the simplest single level parent/child case yet; I
don't think we can afford to complicate update flow, ie. add {{deleteBy\*}} or
check are there children (btw, they can be commited yet).
We need to come up with universal routine which can handle all cases below via
the single API entry point [IW.updateDocuments(delTerm,
docs)|https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java#L1299]
or establish the new one:
- add with/without children
- update (overwrite) with/without children
- let to omit uniquKey in schema, it this case it won't overwrite itself
just to remind, now it work as {{delTerm=$uniqueKey:get($uniqueKey)}} for
childless, and {{delTerm=\_root_:get($uniqueKey)}}. here is the problem.
IMHO, -if we just allow $uniqueKey to span across a whole block (q=id:33
returns a block of several docs), it would be nobrainer, which solves
everything.- Let's just *always* copy $uniqueKey to \_root_ spans it to all
children and use \_root_:get($uniqueKey) as a delete term,
What I'm missing?
was (Author: mkhludnev):
I want to emphasize two things: multilevel nesting is out of scope so far, just
because we can't deal with the simplest single level parent/child case yet; I
don't think we can afford to complicate update flow, ie. add {{deleteBy\*}} or
check are there children (btw, they can be commited yet).
We need to come up with universal routine which can handle all cases below via
the single API entry point [IW.updateDocuments(delTerm,
docs)|https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java#L1299]
or establish the new one:
- add with/without children
- update (overwrite) with/without children
- let to omit uniquKey in schema, it this case it won't overwrite itself
just to remind, now it work as {{delTerm=$uniqueKey:get($uniqueKey)}} for
childless, and {{delTerm=\_root_:get($uniqueKey)}}. here is the problem.
IMHO, if we just allow $uniqueKey to span across a whole block (q=id:33 returns
a block of several docs), it would be nobrainer, which solves everything.
What I'm missing?
> 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, Trunk
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Fix For: Trunk, 5.5
>
>
> 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
(v6.3.4#6332)
-
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=15038352#comment-15038352
]
Mikhail Khludnev edited comment on SOLR-5211 at 12/4/15 7:34 AM:
-
I want to address this. Thus, we have to assign identifier spans across whole
block. However it makes semantics odd. Even if you send a single
document, it _moves_ {{uniqueKey}} field value into {{\_root_}} field (as-is).
Otherwise, we can propagate {{uniqueKey}} to whole block, but it would seem
contradictionary.
Which way would you like?
was (Author: mkhludnev):
I want to address this. Thus, we have to assign identifier spans across whole
block. However it makes semantics odd. Even if you send a single
document, it _moves_ {{uniqueKey}} field value into {{_root_}} field (as-is).
Otherwise, we can propagate {{uniqueKey}} to whole block, but it would seem
contradictionary.
Which way would you like?
> 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, Trunk
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Fix For: Trunk, 5.5
>
>
> 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
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
