[ https://issues.apache.org/jira/browse/SOLR-12926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664022#comment-16664022 ]
David Smiley commented on SOLR-12926: ------------------------------------- [~ichattopadhyaya] I see you modified {{org.apache.solr.handler.component.RealTimeGetComponent#getInputDocumentFromTlog}} to have the AtomicLong parameter for SOLR-5944 Can you shed some light here? > TransactionLog version consistency with doc's _version_ > ------------------------------------------------------- > > Key: SOLR-12926 > URL: https://issues.apache.org/jira/browse/SOLR-12926 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud > Reporter: David Smiley > Priority: Major > > In the TransactionLog I see that there's some metadata for the document -- > it's ID and a version (a long). Should the \_version\_ in the document be > the same as this metadata (which gets there via UpdateCommand.getVersion ? > Sometimes the doc doesn't have a version field so lets assume it's 0 (same as > UpdateCommand's default). I added an assertion on write() that checks they > are consistent and I found one test that failed (metadata=0, > doc=1615316737550450688) > {{org.apache.solr.cloud.MigrateRouteKeyTest#multipleShardMigrateTest}} > * So should they always be consistent? If so... > * We should assert this (I'll attach a quick 'n dirty patch of this) > * Document UpdateCommand.getVersion > * > org.apache.solr.handler.component.RealTimeGetComponent#getInputDocumentFromTlog > is too complicated in taking AtomicLong as an "out" parameter. If the > caller wants the version, they should get it themselves from the document > like any normal field. > -- 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