[jira] Updated: (SOLR-1244) JdbcDataSource uses wrong overload of getConnection on JNDI DataSource
[ https://issues.apache.org/jira/browse/SOLR-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1244: - Attachment: SOLR-1244.patch synced w/ trunk . I shall commit this shortly > JdbcDataSource uses wrong overload of getConnection on JNDI DataSource > -- > > Key: SOLR-1244 > URL: https://issues.apache.org/jira/browse/SOLR-1244 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 > Environment: Any. >Reporter: Chris Eldredge >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1244.patch, SOLR-1244.patch > > > When configured to use a JDBC DataSource via JNDI, JdbcDataSource checks to > see if initProps contains a property named "user." If that property is null, > DataSource.getConnection(String user, String password) is used where > DataSource.getConnection() should be called. I will provide a test case and > patch that fixes the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1244) JdbcDataSource uses wrong overload of getConnection on JNDI DataSource
[ https://issues.apache.org/jira/browse/SOLR-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1244: - Fix Version/s: 1.4 > JdbcDataSource uses wrong overload of getConnection on JNDI DataSource > -- > > Key: SOLR-1244 > URL: https://issues.apache.org/jira/browse/SOLR-1244 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 > Environment: Any. >Reporter: Chris Eldredge >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1244.patch > > > When configured to use a JDBC DataSource via JNDI, JdbcDataSource checks to > see if initProps contains a property named "user." If that property is null, > DataSource.getConnection(String user, String password) is used where > DataSource.getConnection() should be called. I will provide a test case and > patch that fixes the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1245) DIH eats up SQL exception
[ https://issues.apache.org/jira/browse/SOLR-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1245: - Attachment: SOLR-1245.patch > DIH eats up SQL exception > - > > Key: SOLR-1245 > URL: https://issues.apache.org/jira/browse/SOLR-1245 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1245.patch > > > see the mail thread http://markmail.org/thread/bdzhwch7ivkuvmk2 > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:326) > > should throw an exception back -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1245) DIH eats up SQL exception
[ https://issues.apache.org/jira/browse/SOLR-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1245: Assignee: Noble Paul > DIH eats up SQL exception > - > > Key: SOLR-1245 > URL: https://issues.apache.org/jira/browse/SOLR-1245 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > > see the mail thread http://markmail.org/thread/bdzhwch7ivkuvmk2 > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:326) > > should throw an exception back -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1244) JdbcDataSource uses wrong overload of getConnection on JNDI DataSource
[ https://issues.apache.org/jira/browse/SOLR-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1244: Assignee: Noble Paul > JdbcDataSource uses wrong overload of getConnection on JNDI DataSource > -- > > Key: SOLR-1244 > URL: https://issues.apache.org/jira/browse/SOLR-1244 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 > Environment: Any. >Reporter: Chris Eldredge >Assignee: Noble Paul > Attachments: SOLR-1244.patch > > > When configured to use a JDBC DataSource via JNDI, JdbcDataSource checks to > see if initProps contains a property named "user." If that property is null, > DataSource.getConnection(String user, String password) is used where > DataSource.getConnection() should be called. I will provide a test case and > patch that fixes the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1245) DIH eats up SQL exception
DIH eats up SQL exception - Key: SOLR-1245 URL: https://issues.apache.org/jira/browse/SOLR-1245 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Noble Paul Priority: Minor Fix For: 1.4 see the mail thread http://markmail.org/thread/bdzhwch7ivkuvmk2 org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:326) should throw an exception back -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1145) Patch to set IndexWriter.defaultInfoStream from solr.xml
[ https://issues.apache.org/jira/browse/SOLR-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723584#action_12723584 ] Noble Paul commented on SOLR-1145: -- I am moving all the xpath reading to solrconfig. I guess this too can go to solrconfig. SOLR-1198 > Patch to set IndexWriter.defaultInfoStream from solr.xml > > > Key: SOLR-1145 > URL: https://issues.apache.org/jira/browse/SOLR-1145 > Project: Solr > Issue Type: Improvement >Reporter: Chris Harris >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: SOLR-1145.patch, SOLR-1145.patch, SOLR-1145.patch, > SOLR-1145.patch > > > Lucene IndexWriters use an infoStream to log detailed info about indexing > operations for debugging purpose. This patch is an extremely simple way to > allow logging this info to a file from within Solr: After applying the patch, > set the new "defaultInfoStreamFilePath" attribute of the solr element in > solr.xml to the path of the file where you'd like to save the logging > information. > Note that, in a multi-core setup, all cores will end up logging to the same > infoStream log file. This may not be desired. (But it does justify putting > the setting in solr.xml rather than solrconfig.xml.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SOLR-1239) org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest FAILED
[ https://issues.apache.org/jira/browse/SOLR-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul closed SOLR-1239. Resolution: Fixed this got resolved as part of SOLR-1214 > org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest FAILED > -- > > Key: SOLR-1239 > URL: https://issues.apache.org/jira/browse/SOLR-1239 > Project: Solr > Issue Type: Bug >Reporter: Noble Paul > Fix For: 1.4 > > > this testcase fails -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1229) deletedPkQuery feature does not work when pk and uniqueKey field do not have the same value
[
https://issues.apache.org/jira/browse/SOLR-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723427#action_12723427
]
Noble Paul commented on SOLR-1229:
--
hi Erik it works in your case , But the usecase I have given above (which is a
more normal usecase)
let me explain with the above example .
{code:java}
// this code is taken from your patch
SchemaField uniqueKeyField = dataImporter.getSchema().getUniqueKeyField();
// now the value of uniqueKeyField is 'solr_id'
if (uniqueKeyField == null) return;
Object key = map.get(uniqueKeyField.getName());
//the map contains {"db_id"-> "12345"}
//so key == null; and it will do nothing and return
// on the contrary if you set the pk="db_id" , then it works
{code}
> deletedPkQuery feature does not work when pk and uniqueKey field do not have
> the same value
> ---
>
> Key: SOLR-1229
> URL: https://issues.apache.org/jira/browse/SOLR-1229
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Erik Hatcher
> Fix For: 1.4
>
> Attachments: SOLR-1229.patch, SOLR-1229.patch, SOLR-1229.patch
>
>
> Problem doing a delta-import such that records marked as "deleted" in the
> database are removed from Solr using deletedPkQuery.
> Here's a config I'm using against a mocked test database:
> {code:xml}
>
>
>
>pk="board_id"
>transformer="TemplateTransformer"
>deletedPkQuery="select board_id from boards where deleted = 'Y'"
>query="select * from boards where deleted = 'N'"
>deltaImportQuery="select * from boards where deleted = 'N'"
>deltaQuery="select * from boards where deleted = 'N'"
>preImportDeleteQuery="datasource:board">
>
>
>
>
>
>
> {code}
> Note that the uniqueKey in Solr is the "id" field. And its value is a
> template board-.
> I noticed the javadoc comments in DocBuilder#collectDelta it says "Note: In
> our definition, unique key of Solr document is the primary key of the top
> level entity". This of course isn't really an appropriate assumption.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1239) org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest FAILED
org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest FAILED -- Key: SOLR-1239 URL: https://issues.apache.org/jira/browse/SOLR-1239 Project: Solr Issue Type: Bug Reporter: Noble Paul Fix For: 1.4 this testcase fails -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1238) exception in solrJ when authentication is used
[
https://issues.apache.org/jira/browse/SOLR-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1238:
-
Attachment: SOLR-1238.patch
> exception in solrJ when authentication is used
> --
>
> Key: SOLR-1238
> URL: https://issues.apache.org/jira/browse/SOLR-1238
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 1.3
>Reporter: Noble Paul
>Priority: Minor
> Attachments: SOLR-1238.patch
>
>
> see the thread http://markmail.org/thread/w36ih2fnphbubian
> {code}
> I am facing getting error when I am using Authentication in Solr. I
> followed Wiki. The error doesnot appear when I searching. Below is the
> code snippet and the error.
> Please note I am using Solr 1.4 Development build from SVN.
>HttpClient client=new HttpClient();
>AuthScope scope = new
> AuthScope(AuthScope.ANY_HOST,AuthScope.ANY_PORT,null, null);
>client.getState().setCredentials(scope,new
> UsernamePasswordCredentials("guest", "guest"));
>SolrServer server =new
> CommonsHttpSolrServer("http://localhost:8983/solr",client);
>SolrInputDocument doc1=new SolrInputDocument();
>//Add fields to the document
>doc1.addField("employeeid", "1237");
>doc1.addField("employeename", "Ann");
>doc1.addField("employeeunit", "etc");
>doc1.addField("employeedoj", "1995-11-31T23:59:59Z");
>server.add(doc1);
> Exception in thread "main"
> org.apache.solr.client.solrj.SolrServerException:
> org.apache.commons.httpclient.ProtocolException: Unbuffered entity
> enclosing request can not be repeated.
>at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:468)
>at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:242)
>at
> org.apache.solr.client.solrj.request.UpdateRequest.process(UpdateRequest.java:259)
>at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:63)
>at test.SolrAuthenticationTest.(SolrAuthenticationTest.java:49)
>at test.SolrAuthenticationTest.main(SolrAuthenticationTest.java:113)
> Caused by: org.apache.commons.httpclient.ProtocolException: Unbuffered
> entity enclosing request can not be repeated.
>at
> org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:487)
>at
> org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114)
>at
> org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
>at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
>at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
>at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
>at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
>at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:415)
>... 5 more.
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1238) exception in solrJ when authentication is used
exception in solrJ when authentication is used
--
Key: SOLR-1238
URL: https://issues.apache.org/jira/browse/SOLR-1238
Project: Solr
Issue Type: Bug
Components: clients - java
Affects Versions: 1.3
Reporter: Noble Paul
Priority: Minor
see the thread http://markmail.org/thread/w36ih2fnphbubian
{code}
I am facing getting error when I am using Authentication in Solr. I
followed Wiki. The error doesnot appear when I searching. Below is the
code snippet and the error.
Please note I am using Solr 1.4 Development build from SVN.
HttpClient client=new HttpClient();
AuthScope scope = new
AuthScope(AuthScope.ANY_HOST,AuthScope.ANY_PORT,null, null);
client.getState().setCredentials(scope,new
UsernamePasswordCredentials("guest", "guest"));
SolrServer server =new
CommonsHttpSolrServer("http://localhost:8983/solr",client);
SolrInputDocument doc1=new SolrInputDocument();
//Add fields to the document
doc1.addField("employeeid", "1237");
doc1.addField("employeename", "Ann");
doc1.addField("employeeunit", "etc");
doc1.addField("employeedoj", "1995-11-31T23:59:59Z");
server.add(doc1);
Exception in thread "main"
org.apache.solr.client.solrj.SolrServerException:
org.apache.commons.httpclient.ProtocolException: Unbuffered entity
enclosing request can not be repeated.
at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:468)
at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:242)
at
org.apache.solr.client.solrj.request.UpdateRequest.process(UpdateRequest.java:259)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:63)
at test.SolrAuthenticationTest.(SolrAuthenticationTest.java:49)
at test.SolrAuthenticationTest.main(SolrAuthenticationTest.java:113)
Caused by: org.apache.commons.httpclient.ProtocolException: Unbuffered
entity enclosing request can not be repeated.
at
org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:487)
at
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:415)
... 5 more.
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1234) Multiple DIH does not work because all of them write to dataimport.properties
[ https://issues.apache.org/jira/browse/SOLR-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1234: - Attachment: SOLR-1234.patch removes first slash and replaces all other slashes w/ underscores > Multiple DIH does not work because all of them write to dataimport.properties > - > > Key: SOLR-1234 > URL: https://issues.apache.org/jira/browse/SOLR-1234 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1234.patch, SOLR-1234.patch > > > DIH always writes the details to /dataimport.properties. This is a > problem if multiple DIH entries need to be used. The simplest solution would > be to write to a file name that is same as the handler name (this is unique > anyway) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1229) deletedPkQuery feature does not work when pk and uniqueKey field do not have the same value
[
https://issues.apache.org/jira/browse/SOLR-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722956#action_12722956
]
Noble Paul edited comment on SOLR-1229 at 6/22/09 9:45 PM:
---
bq.he pk attribute seems like it should simply be removed
The pk attribute IS REQUIRED for this use case. I guess the solution to your
problem is that you set the pk correct as the name you find in the "source row"
map. if we remove it every user will be forced to keep the uniquekey same as
the name it has in the source DB.
Take the following usecase
{code:xml}
{code}
elsewhere in solrconfig.xml
{code:xml}
solr_id
{code}
if you omit that pk attributethis will fail
was (Author: noble.paul):
bq.he pk attribute seems like it should simply be removed
The pk attribute IS REQUIRED for this use case. I guess the solution to your
problem is that you set the pk correct as the name you find in the "source row"
map. if we remove it every user will be forced to keep the uniquekey same as
the name it has in the source DB.
> deletedPkQuery feature does not work when pk and uniqueKey field do not have
> the same value
> ---
>
> Key: SOLR-1229
> URL: https://issues.apache.org/jira/browse/SOLR-1229
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Erik Hatcher
> Fix For: 1.4
>
> Attachments: SOLR-1229.patch, SOLR-1229.patch, SOLR-1229.patch
>
>
> Problem doing a delta-import such that records marked as "deleted" in the
> database are removed from Solr using deletedPkQuery.
> Here's a config I'm using against a mocked test database:
> {code:xml}
>
>
>
>pk="board_id"
>transformer="TemplateTransformer"
>deletedPkQuery="select board_id from boards where deleted = 'Y'"
>query="select * from boards where deleted = 'N'"
>deltaImportQuery="select * from boards where deleted = 'N'"
>deltaQuery="select * from boards where deleted = 'N'"
>preImportDeleteQuery="datasource:board">
>
>
>
>
>
>
> {code}
> Note that the uniqueKey in Solr is the "id" field. And its value is a
> template board-.
> I noticed the javadoc comments in DocBuilder#collectDelta it says "Note: In
> our definition, unique key of Solr document is the primary key of the top
> level entity". This of course isn't really an appropriate assumption.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1229) deletedPkQuery feature does not work when pk and uniqueKey field do not have the same value
[
https://issues.apache.org/jira/browse/SOLR-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722956#action_12722956
]
Noble Paul commented on SOLR-1229:
--
bq.he pk attribute seems like it should simply be removed
The pk attribute IS REQUIRED for this use case. I guess the solution to your
problem is that you set the pk correct as the name you find in the "source row"
map. if we remove it every user will be forced to keep the uniquekey same as
the name it has in the source DB.
> deletedPkQuery feature does not work when pk and uniqueKey field do not have
> the same value
> ---
>
> Key: SOLR-1229
> URL: https://issues.apache.org/jira/browse/SOLR-1229
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Erik Hatcher
> Fix For: 1.4
>
> Attachments: SOLR-1229.patch, SOLR-1229.patch, SOLR-1229.patch
>
>
> Problem doing a delta-import such that records marked as "deleted" in the
> database are removed from Solr using deletedPkQuery.
> Here's a config I'm using against a mocked test database:
> {code:xml}
>
>
>
>pk="board_id"
>transformer="TemplateTransformer"
>deletedPkQuery="select board_id from boards where deleted = 'Y'"
>query="select * from boards where deleted = 'N'"
>deltaImportQuery="select * from boards where deleted = 'N'"
>deltaQuery="select * from boards where deleted = 'N'"
>preImportDeleteQuery="datasource:board">
>
>
>
>
>
>
> {code}
> Note that the uniqueKey in Solr is the "id" field. And its value is a
> template board-.
> I noticed the javadoc comments in DocBuilder#collectDelta it says "Note: In
> our definition, unique key of Solr document is the primary key of the top
> level entity". This of course isn't really an appropriate assumption.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1234) Multiple DIH does not work because all of them write to dataimport.properties
[ https://issues.apache.org/jira/browse/SOLR-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722948#action_12722948 ] Noble Paul commented on SOLR-1234: -- how would those multiple slashes look like ? name="/dataimport/d1" ? I never knew it existed. > Multiple DIH does not work because all of them write to dataimport.properties > - > > Key: SOLR-1234 > URL: https://issues.apache.org/jira/browse/SOLR-1234 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1234.patch > > > DIH always writes the details to /dataimport.properties. This is a > problem if multiple DIH entries need to be used. The simplest solution would > be to write to a file name that is same as the handler name (this is unique > anyway) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1216) disambiguate the replication command names
[ https://issues.apache.org/jira/browse/SOLR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1216. -- Resolution: Fixed committed : r787212 > disambiguate the replication command names > -- > > Key: SOLR-1216 > URL: https://issues.apache.org/jira/browse/SOLR-1216 > Project: Solr > Issue Type: Improvement > Components: replication (java) >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1216.patch, SOLR-1216.patch > > > There is a lot of confusion in the naming of various commands such as > snappull, snapshot etc. This is a vestige of the script based replication we > currently have. The commands can be renamed to make more sense > * 'snappull' to be renamed to 'sync' > * 'snapshot' to be renamed to 'backup' > thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1216) disambiguate the replication command names
[ https://issues.apache.org/jira/browse/SOLR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1216: - Attachment: SOLR-1216.patch 'fetchindex 'and 'abortfetch' are the commands. I shall commit this shortly > disambiguate the replication command names > -- > > Key: SOLR-1216 > URL: https://issues.apache.org/jira/browse/SOLR-1216 > Project: Solr > Issue Type: Improvement > Components: replication (java) >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1216.patch, SOLR-1216.patch > > > There is a lot of confusion in the naming of various commands such as > snappull, snapshot etc. This is a vestige of the script based replication we > currently have. The commands can be renamed to make more sense > * 'snappull' to be renamed to 'sync' > * 'snapshot' to be renamed to 'backup' > thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1234) Multiple DIH does not work because all of them write to dataimport.properties
[ https://issues.apache.org/jira/browse/SOLR-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1234. -- Resolution: Fixed committed r787205 > Multiple DIH does not work because all of them write to dataimport.properties > - > > Key: SOLR-1234 > URL: https://issues.apache.org/jira/browse/SOLR-1234 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1234.patch > > > DIH always writes the details to /dataimport.properties. This is a > problem if multiple DIH entries need to be used. The simplest solution would > be to write to a file name that is same as the handler name (this is unique > anyway) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1235) disallow period (.) in entity names
[ https://issues.apache.org/jira/browse/SOLR-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1235. -- Resolution: Fixed committed r787139 > disallow period (.) in entity names > --- > > Key: SOLR-1235 > URL: https://issues.apache.org/jira/browse/SOLR-1235 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > > periods do not work because it is a special char for resolving namespaces -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1235) disallow period (.) in entity names
[ https://issues.apache.org/jira/browse/SOLR-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1235: Assignee: Noble Paul > disallow period (.) in entity names > --- > > Key: SOLR-1235 > URL: https://issues.apache.org/jira/browse/SOLR-1235 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > > periods do not work because it is a special char for resolving namespaces -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1235) disallow period (.) in entity names
disallow period (.) in entity names --- Key: SOLR-1235 URL: https://issues.apache.org/jira/browse/SOLR-1235 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.3 Reporter: Noble Paul Priority: Minor Fix For: 1.4 periods do not work because it is a special char for resolving namespaces -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1234) Multiple DIH does not work because all of them write to dataimport.properties
[ https://issues.apache.org/jira/browse/SOLR-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1234: - Attachment: SOLR-1234.patch > Multiple DIH does not work because all of them write to dataimport.properties > - > > Key: SOLR-1234 > URL: https://issues.apache.org/jira/browse/SOLR-1234 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1234.patch > > > DIH always writes the details to /dataimport.properties. This is a > problem if multiple DIH entries need to be used. The simplest solution would > be to write to a file name that is same as the handler name (this is unique > anyway) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1234) Multiple DIH does not work because all of them write to dataimport.properties
Multiple DIH does not work because all of them write to dataimport.properties - Key: SOLR-1234 URL: https://issues.apache.org/jira/browse/SOLR-1234 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.3 Reporter: Noble Paul Assignee: Noble Paul Fix For: 1.4 DIH always writes the details to /dataimport.properties. This is a problem if multiple DIH entries need to be used. The simplest solution would be to write to a file name that is same as the handler name (this is unique anyway) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1229) deletedPkQuery feature does not work when pk and uniqueKey field do not have the same value
[
https://issues.apache.org/jira/browse/SOLR-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722473#action_12722473
]
Noble Paul commented on SOLR-1229:
--
bq.If the pk attribute is not used, then let's just remove it altogether.
hi Erik. you got me wrong. Let me try to explain. There are two potential
names for a field one is the 'column' and other is the 'name'
'column' is the name of the field in the source or in DIH. The 'name' is the
name of that field in Solr. DIH uses the 'name' attribute only when it writes
the field to Solr.
The relation ship between 'pk' attribute and the '' in Solr is same
. The distinction is important . Otherwise the user will be forced to use the
same name in both the db and solr (assuming no transformations are done).
> deletedPkQuery feature does not work when pk and uniqueKey field do not have
> the same value
> ---
>
> Key: SOLR-1229
> URL: https://issues.apache.org/jira/browse/SOLR-1229
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Erik Hatcher
> Fix For: 1.4
>
> Attachments: SOLR-1229.patch, SOLR-1229.patch, SOLR-1229.patch,
> SOLR-1229.patch
>
>
> Problem doing a delta-import such that records marked as "deleted" in the
> database are removed from Solr using deletedPkQuery.
> Here's a config I'm using against a mocked test database:
> {code:xml}
>
>
>
>pk="board_id"
>transformer="TemplateTransformer"
>deletedPkQuery="select board_id from boards where deleted = 'Y'"
>query="select * from boards where deleted = 'N'"
>deltaImportQuery="select * from boards where deleted = 'N'"
>deltaQuery="select * from boards where deleted = 'N'"
>preImportDeleteQuery="datasource:board">
>
>
>
>
>
>
> {code}
> Note that the uniqueKey in Solr is the "id" field. And its value is a
> template board-.
> I noticed the javadoc comments in DocBuilder#collectDelta it says "Note: In
> our definition, unique key of Solr document is the primary key of the top
> level entity". This of course isn't really an appropriate assumption.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1229) deletedPkQuery feature does not work when pk and uniqueKey field do not have the same value
[
https://issues.apache.org/jira/browse/SOLR-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722354#action_12722354
]
Noble Paul edited comment on SOLR-1229 at 6/21/09 6:09 AM:
---
bq.But in order to call writer.deleteDoc(key) in DocBuilder#deleteAll it must
use the value of the uniqueKey field, not of the pk one
Why can't you keep the uniqueKey same as pk as shown below(it is not used
anywhere else (yes there is one other place which is gonna be deprecated) ) .
That should solve the problem. DIH is agnostic of the solr primary key . The
point is that , the key name does not matter only the value matters . As long
as the value is correct, delete should work automatically .
the following should be just fine
{code:xml}
deletedPkQuery feature does not work when pk and uniqueKey field do not have
> the same value
> ---
>
> Key: SOLR-1229
> URL: https://issues.apache.org/jira/browse/SOLR-1229
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Erik Hatcher
> Fix For: 1.4
>
> Attachments: SOLR-1229.patch, SOLR-1229.patch
>
>
> Problem doing a delta-import such that records marked as "deleted" in the
> database are removed from Solr using deletedPkQuery.
> Here's a config I'm using against a mocked test database:
>
>
>
>pk="board_id"
>transformer="TemplateTransformer"
>deletedPkQuery="select board_id from boards where deleted = 'Y'"
>query="select * from boards where deleted = 'N'"
>deltaImportQuery="select * from boards where deleted = 'N'"
>deltaQuery="select * from boards where deleted = 'N'"
>preImportDeleteQuery="datasource:board">
>
>
>
>
>
>
> Note that the uniqueKey in Solr is the "id" field. And its value is a
> template board-.
> I noticed the javadoc comments in DocBuilder#collectDelta it says "Note: In
> our definition, unique key of Solr document is the primary key of the top
> level entity". This of course isn't really an appropriate assumption.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1229) deletedPkQuery feature does not work when pk and uniqueKey field do not have the same value
[ https://issues.apache.org/jira/browse/SOLR-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722354#action_12722354 ] Noble Paul commented on SOLR-1229: -- bq.But in order to call writer.deleteDoc(key) in DocBuilder#deleteAll it must use the value of the uniqueKey field, not of the pk one Why can't you keep the uniqueKey same as pk (it is not used anywhere else (yes there is one other place which is gonna be deprecated) ) . That should solve the problem. DIH is agnostic of the solr primary key . The point is that , the key name does not matter only the value matters . As long as the value is correct, delete should work automatically . > deletedPkQuery feature does not work when pk and uniqueKey field do not have > the same value > --- > > Key: SOLR-1229 > URL: https://issues.apache.org/jira/browse/SOLR-1229 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Erik Hatcher > Fix For: 1.4 > > Attachments: SOLR-1229.patch, SOLR-1229.patch > > > Problem doing a delta-import such that records marked as "deleted" in the > database are removed from Solr using deletedPkQuery. > Here's a config I'm using against a mocked test database: > > > >pk="board_id" >transformer="TemplateTransformer" >deletedPkQuery="select board_id from boards where deleted = 'Y'" >query="select * from boards where deleted = 'N'" >deltaImportQuery="select * from boards where deleted = 'N'" >deltaQuery="select * from boards where deleted = 'N'" >preImportDeleteQuery="datasource:board"> > > > > > > > Note that the uniqueKey in Solr is the "id" field. And its value is a > template board-. > I noticed the javadoc comments in DocBuilder#collectDelta it says "Note: In > our definition, unique key of Solr document is the primary key of the top > level entity". This of course isn't really an appropriate assumption. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1229) deletedPkQuery feature does not work when pk and uniqueKey field do not have the same value
[
https://issues.apache.org/jira/browse/SOLR-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722333#action_12722333
]
Noble Paul commented on SOLR-1229:
--
Erik, the fix is not right
see this
{code}
key = map.get(dataImporter.getSchema().getUniqueKeyField().getName());
{code}
The name of the uniqueKey field in the scema and the one you have in the map
does not have to be same. DIH really gives you an option for it to be
different. The attribute 'pk' is only used for this purpose.
> deletedPkQuery feature does not work when pk and uniqueKey field do not have
> the same value
> ---
>
> Key: SOLR-1229
> URL: https://issues.apache.org/jira/browse/SOLR-1229
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Erik Hatcher
> Fix For: 1.4
>
> Attachments: SOLR-1229.patch, SOLR-1229.patch
>
>
> Problem doing a delta-import such that records marked as "deleted" in the
> database are removed from Solr using deletedPkQuery.
> Here's a config I'm using against a mocked test database:
>
>
>
>pk="board_id"
>transformer="TemplateTransformer"
>deletedPkQuery="select board_id from boards where deleted = 'Y'"
>query="select * from boards where deleted = 'N'"
>deltaImportQuery="select * from boards where deleted = 'N'"
>deltaQuery="select * from boards where deleted = 'N'"
>preImportDeleteQuery="datasource:board">
>
>
>
>
>
>
> Note that the uniqueKey in Solr is the "id" field. And its value is a
> template board-.
> I noticed the javadoc comments in DocBuilder#collectDelta it says "Note: In
> our definition, unique key of Solr document is the primary key of the top
> level entity". This of course isn't really an appropriate assumption.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1191) NullPointerException in delta import
[
https://issues.apache.org/jira/browse/SOLR-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722332#action_12722332
]
Noble Paul commented on SOLR-1191:
--
The stacktrace does not refer to trunk. can you just let me know which version
you were using? I fixed another NPE recently w/ delta-import. I am not too sure
if it is the same
> NullPointerException in delta import
>
>
> Key: SOLR-1191
> URL: https://issues.apache.org/jira/browse/SOLR-1191
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.3, 1.4
> Environment: OS: Windows & Linux.
> Java: 1.6
> DB: MySQL & SQL Server
>Reporter: Ali Syed
>Assignee: Noble Paul
> Fix For: 1.4
>
>
> Seeing few of these NullPointerException during delta imports. Once this
> happens delta import stops working and keeps giving the same error.
> java.lang.NullPointerException
> at
> org.apache.solr.handler.dataimport.DocBuilder.collectDelta(DocBuilder.java:622)
> at
> org.apache.solr.handler.dataimport.DocBuilder.doDelta(DocBuilder.java:240)
> at
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:159)
> at
> org.apache.solr.handler.dataimport.DataImporter.doDeltaImport(DataImporter.java:337)
> at
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:376)
> at
> org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:355)
> Running delta import for a particular entity fixes the problem and delta
> import start working again.
> Here is the log just before & after the exception
> 05/27 11:59:29 86987686 INFO btpool0-538 org.apache.solr.core.SolrCore -
> [localhost] webapp=/solr path=/dataimport
> params={command=delta-import&optimize=false} status=0 QTime=0
> 05/27 11:59:29 86987687 INFO Thread-4162
> org.apache.solr.handler.dataimport.SolrWriter - Read dataimport.properties
> 05/27 11:59:29 86987687 INFO Thread-4162
> org.apache.solr.handler.dataimport.DataImporter - Starting Delta Import
> 05/27 11:59:29 86987687 INFO Thread-4162
> org.apache.solr.handler.dataimport.SolrWriter - Read dataimport.properties
> 05/27 11:59:29 86987687 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Starting delta collection.
> 05/27 11:59:29 86987690 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Running ModifiedRowKey() for
> Entity: content
> 05/27 11:59:29 86987690 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed ModifiedRowKey for
> Entity: content rows obtained : 0
> 05/27 11:59:29 86987690 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed DeletedRowKey for
> Entity: content rows obtained : 0
> 05/27 11:59:29 86987692 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed parentDeltaQuery
> for Entity: content
> 05/27 11:59:29 86987692 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Running ModifiedRowKey() for
> Entity: job
> 05/27 11:59:29 86987692 INFO Thread-4162
> org.apache.solr.handler.dataimport.JdbcDataSource - Creating a connection
> for entity job with URL: jdbc:sqlserver://localhost;databaseName=TestDB
> 05/27 11:59:29 86987704 INFO Thread-4162
> org.apache.solr.handler.dataimport.JdbcDataSource - Time taken for
> getConnection(): 12
> 05/27 11:59:29 86987707 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed ModifiedRowKey for
> Entity: job rows obtained : 0
> 05/27 11:59:29 86987707 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed DeletedRowKey for
> Entity: job rows obtained : 0
> 05/27 11:59:29 86987707 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed parentDeltaQuery
> for Entity: job
> 05/27 11:59:29 86987707 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Delta Import completed
> successfully
> 05/27 11:59:29 86987707 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Starting delta collection.
> 05/27 11:59:29 86987709 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Running ModifiedRowKey() for
> Entity: user
> 05/27 11:59:29 86987709 INFO Thread-4162
> org.apache.solr.handler.dataimport.JdbcDataSource - Creating a connection
> for entity user with URL: jdbc:sqlserver://localhost;databaseName=TestDB
> 05/27 11:59:29 86987716 INFO Thread-4162
> org.apache.solr.handler.dataimport.JdbcDataSource - Time taken for
> getConnection(): 7
> 05/27 11:59:29 86987873 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed ModifiedRowKey for
> Entity: user rows obtained : 46
> 05/27 11:59:29 86987873 INFO Thread-4162
> org.apach
[jira] Assigned: (SOLR-1191) NullPointerException in delta import
[
https://issues.apache.org/jira/browse/SOLR-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-1191:
Assignee: Noble Paul
> NullPointerException in delta import
>
>
> Key: SOLR-1191
> URL: https://issues.apache.org/jira/browse/SOLR-1191
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.3, 1.4
> Environment: OS: Windows & Linux.
> Java: 1.6
> DB: MySQL & SQL Server
>Reporter: Ali Syed
>Assignee: Noble Paul
> Fix For: 1.4
>
>
> Seeing few of these NullPointerException during delta imports. Once this
> happens delta import stops working and keeps giving the same error.
> java.lang.NullPointerException
> at
> org.apache.solr.handler.dataimport.DocBuilder.collectDelta(DocBuilder.java:622)
> at
> org.apache.solr.handler.dataimport.DocBuilder.doDelta(DocBuilder.java:240)
> at
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:159)
> at
> org.apache.solr.handler.dataimport.DataImporter.doDeltaImport(DataImporter.java:337)
> at
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:376)
> at
> org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:355)
> Running delta import for a particular entity fixes the problem and delta
> import start working again.
> Here is the log just before & after the exception
> 05/27 11:59:29 86987686 INFO btpool0-538 org.apache.solr.core.SolrCore -
> [localhost] webapp=/solr path=/dataimport
> params={command=delta-import&optimize=false} status=0 QTime=0
> 05/27 11:59:29 86987687 INFO Thread-4162
> org.apache.solr.handler.dataimport.SolrWriter - Read dataimport.properties
> 05/27 11:59:29 86987687 INFO Thread-4162
> org.apache.solr.handler.dataimport.DataImporter - Starting Delta Import
> 05/27 11:59:29 86987687 INFO Thread-4162
> org.apache.solr.handler.dataimport.SolrWriter - Read dataimport.properties
> 05/27 11:59:29 86987687 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Starting delta collection.
> 05/27 11:59:29 86987690 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Running ModifiedRowKey() for
> Entity: content
> 05/27 11:59:29 86987690 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed ModifiedRowKey for
> Entity: content rows obtained : 0
> 05/27 11:59:29 86987690 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed DeletedRowKey for
> Entity: content rows obtained : 0
> 05/27 11:59:29 86987692 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed parentDeltaQuery
> for Entity: content
> 05/27 11:59:29 86987692 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Running ModifiedRowKey() for
> Entity: job
> 05/27 11:59:29 86987692 INFO Thread-4162
> org.apache.solr.handler.dataimport.JdbcDataSource - Creating a connection
> for entity job with URL: jdbc:sqlserver://localhost;databaseName=TestDB
> 05/27 11:59:29 86987704 INFO Thread-4162
> org.apache.solr.handler.dataimport.JdbcDataSource - Time taken for
> getConnection(): 12
> 05/27 11:59:29 86987707 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed ModifiedRowKey for
> Entity: job rows obtained : 0
> 05/27 11:59:29 86987707 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed DeletedRowKey for
> Entity: job rows obtained : 0
> 05/27 11:59:29 86987707 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed parentDeltaQuery
> for Entity: job
> 05/27 11:59:29 86987707 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Delta Import completed
> successfully
> 05/27 11:59:29 86987707 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Starting delta collection.
> 05/27 11:59:29 86987709 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Running ModifiedRowKey() for
> Entity: user
> 05/27 11:59:29 86987709 INFO Thread-4162
> org.apache.solr.handler.dataimport.JdbcDataSource - Creating a connection
> for entity user with URL: jdbc:sqlserver://localhost;databaseName=TestDB
> 05/27 11:59:29 86987716 INFO Thread-4162
> org.apache.solr.handler.dataimport.JdbcDataSource - Time taken for
> getConnection(): 7
> 05/27 11:59:29 86987873 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed ModifiedRowKey for
> Entity: user rows obtained : 46
> 05/27 11:59:29 86987873 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Completed DeletedRowKey for
> Entity: user rows obtained : 0
> 05/27 11:59:29 86987873 INFO Thread-4162
> org.apache.solr.handler.dataimport.DocBuilder - Comple
[jira] Updated: (SOLR-1229) deletedPkQuery feature does not work when pk and uniqueKey field do not have the same value
[ https://issues.apache.org/jira/browse/SOLR-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1229: - Attachment: SOLR-1229.patch Erik plz let me know if this helps. > deletedPkQuery feature does not work when pk and uniqueKey field do not have > the same value > --- > > Key: SOLR-1229 > URL: https://issues.apache.org/jira/browse/SOLR-1229 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Erik Hatcher > Attachments: SOLR-1229.patch > > > Problem doing a delta-import such that records marked as "deleted" in the > database are removed from Solr using deletedPkQuery. > Here's a config I'm using against a mocked test database: > > > >pk="board_id" >transformer="TemplateTransformer" >deletedPkQuery="select board_id from boards where deleted = 'Y'" >query="select * from boards where deleted = 'N'" >deltaImportQuery="select * from boards where deleted = 'N'" >deltaQuery="select * from boards where deleted = 'N'" >preImportDeleteQuery="datasource:board"> > > > > > > > Note that the uniqueKey in Solr is the "id" field. And its value is a > template board-. > I noticed the javadoc comments in DocBuilder#collectDelta it says "Note: In > our definition, unique key of Solr document is the primary key of the top > level entity". This of course isn't really an appropriate assumption. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1154) allow specifying solr configuration file through system property to simplify deployment procedure in certain cases
[
https://issues.apache.org/jira/browse/SOLR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1154:
-
Fix Version/s: (was: 1.4)
1.5
moving to 1.5 as this is already solved
> allow specifying solr configuration file through system property to simplify
> deployment procedure in certain cases
> --
>
> Key: SOLR-1154
> URL: https://issues.apache.org/jira/browse/SOLR-1154
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jianhan
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1154.patch, SOLR-1154.patch
>
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> Hi,
> I wanted to use this parameter to specify different solr configuration files
> for master and slave to simplify deployment procedure. Unfortunately, I can't
> dynamically replace the value of this parameter. Basically, what I want is
>
> SolrRequestFilter
> org.apache.solr.servlet.SolrDispatchFilter
>
> solrconfig-filename
> solrconfig-master.xml
>
>
> for master instance, and
>
> SolrRequestFilter
> org.apache.solr.servlet.SolrDispatchFilter
>
> solrconfig-filename
> solrconfig-slave.xml
>
>
> for slave instance.
> Ideally, if I can use system property for its value like in solrconfig.xml.
> For example,
>
> SolrRequestFilter
> org.apache.solr.servlet.SolrDispatchFilter
>
> solrconfig-filename
> ${solr.config.filename: solrconfig.xml}
>
>
> but I learned that in general we can't use system property in web.xml.
> I realize that I can use replication of config file to achieve this, but I
> thought that creates unnecessary dependencies for slaves on master instance.
> So here is my proposal:
> make SolrDispatchFilter look up another init parameter, say
> 'solrconfig-filename-property', and its value is a system property name, and
> if this property is set, we get the file name, otherwise nothing happens (of
> course, if both exist, 'solrconfig-filename' takes precedence). This will
> give us maximum flexibility of specifying configuration files for different
> instances.
> Your thoughts?
> Thanks,
> Jianhan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1216) disambiguate the replication command names
[ https://issues.apache.org/jira/browse/SOLR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721752#action_12721752 ] Noble Paul commented on SOLR-1216: -- let us choose a name and close this soon > disambiguate the replication command names > -- > > Key: SOLR-1216 > URL: https://issues.apache.org/jira/browse/SOLR-1216 > Project: Solr > Issue Type: Improvement > Components: replication (java) >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1216.patch > > > There is a lot of confusion in the naming of various commands such as > snappull, snapshot etc. This is a vestige of the script based replication we > currently have. The commands can be renamed to make more sense > * 'snappull' to be renamed to 'sync' > * 'snapshot' to be renamed to 'backup' > thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1222) add convenience methods for deleteById to take a list of strings
[ https://issues.apache.org/jira/browse/SOLR-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1222. -- Resolution: Fixed committed: r786465 > add convenience methods for deleteById to take a list of strings > > > Key: SOLR-1222 > URL: https://issues.apache.org/jira/browse/SOLR-1222 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 1.3 >Reporter: Frank Maritato >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1222.patch > > > I have a patch to add methods to SolrServer.java and UpdateRequest.java to > accept a list of Strings for deleteById. > Internally, UpdateRequest uses a list for the single api, but SolrServer > calls process immediately after the single so it would send all my deletes to > the server one by one. This change adds a method to UpdateRequest to add a > List to the internal list, SolrServer calls this method then process > immediately after. > Would be nice if you can get this in for 1.4. > Thanks :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1222) add convenience methods for deleteById to take a list of strings
[ https://issues.apache.org/jira/browse/SOLR-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1222: - Attachment: SOLR-1222.patch > add convenience methods for deleteById to take a list of strings > > > Key: SOLR-1222 > URL: https://issues.apache.org/jira/browse/SOLR-1222 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 1.3 >Reporter: Frank Maritato >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1222.patch > > > I have a patch to add methods to SolrServer.java and UpdateRequest.java to > accept a list of Strings for deleteById. > Internally, UpdateRequest uses a list for the single api, but SolrServer > calls process immediately after the single so it would send all my deletes to > the server one by one. This change adds a method to UpdateRequest to add a > List to the internal list, SolrServer calls this method then process > immediately after. > Would be nice if you can get this in for 1.4. > Thanks :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1222) add convenience methods for deleteById to take a list of strings
[ https://issues.apache.org/jira/browse/SOLR-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1222: Assignee: Noble Paul > add convenience methods for deleteById to take a list of strings > > > Key: SOLR-1222 > URL: https://issues.apache.org/jira/browse/SOLR-1222 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 1.3 >Reporter: Frank Maritato >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > > I have a patch to add methods to SolrServer.java and UpdateRequest.java to > accept a list of Strings for deleteById. > Internally, UpdateRequest uses a list for the single api, but SolrServer > calls process immediately after the single so it would send all my deletes to > the server one by one. This change adds a method to UpdateRequest to add a > List to the internal list, SolrServer calls this method then process > immediately after. > Would be nice if you can get this in for 1.4. > Thanks :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1214) differentiate between solr home and instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1214. -- Resolution: Fixed committed r786434 > differentiate between solr home and instanceDir > --- > > Key: SOLR-1214 > URL: https://issues.apache.org/jira/browse/SOLR-1214 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1214.patch, SOLR-1214.patch > > > There is a lot of confusion on what is an instanceDir in a multicore system. > The CoreContainer must have a field for solrHome and the instanceDir for > each core should be specific to that core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1214) differentiate between solr home and instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1214: - Attachment: SOLR-1214.patch > differentiate between solr home and instanceDir > --- > > Key: SOLR-1214 > URL: https://issues.apache.org/jira/browse/SOLR-1214 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1214.patch, SOLR-1214.patch > > > There is a lot of confusion on what is an instanceDir in a multicore system. > The CoreContainer must have a field for solrHome and the instanceDir for > each core should be specific to that core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1121) CoreAdminhandler should not need a core
[ https://issues.apache.org/jira/browse/SOLR-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1121. -- Resolution: Fixed committed r786416 thanks mark sturlese > CoreAdminhandler should not need a core > --- > > Key: SOLR-1121 > URL: https://issues.apache.org/jira/browse/SOLR-1121 > Project: Solr > Issue Type: New Feature >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1121.patch, SOLR-1121.patch, SOLR-1121.patch > > > Currently it is not possible to start Solr with no cores. because the > CoreAdminHandler can only be invoked with a core. > The CoreAdminHandler does not require anything from the SolrCore Object . We > must remove this dependency -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SOLR-1121) CoreAdminhandler should not need a core
[ https://issues.apache.org/jira/browse/SOLR-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reopened SOLR-1121: -- misses two response writers > CoreAdminhandler should not need a core > --- > > Key: SOLR-1121 > URL: https://issues.apache.org/jira/browse/SOLR-1121 > Project: Solr > Issue Type: New Feature >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1121.patch, SOLR-1121.patch, SOLR-1121.patch > > > Currently it is not possible to start Solr with no cores. because the > CoreAdminHandler can only be invoked with a core. > The CoreAdminHandler does not require anything from the SolrCore Object . We > must remove this dependency -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1229) deletedPkQuery feature does not work when pk and uniqueKey field do not have the same value
[ https://issues.apache.org/jira/browse/SOLR-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721349#action_12721349 ] Noble Paul commented on SOLR-1229: -- there is a huge problem w/ the current implementation. The whole delta-import process is built like an after thought. I wish to revamp the whole design. so that all the rows returned, deletedPkQuery or deltaQuery etc should also go through the transformations > deletedPkQuery feature does not work when pk and uniqueKey field do not have > the same value > --- > > Key: SOLR-1229 > URL: https://issues.apache.org/jira/browse/SOLR-1229 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Erik Hatcher > > Problem doing a delta-import such that records marked as "deleted" in the > database are removed from Solr using deletedPkQuery. > Here's a config I'm using against a mocked test database: > > > >pk="board_id" >transformer="TemplateTransformer" >deletedPkQuery="select board_id from boards where deleted = 'Y'" >query="select * from boards where deleted = 'N'" >deltaImportQuery="select * from boards where deleted = 'N'" >deltaQuery="select * from boards where deleted = 'N'" >preImportDeleteQuery="datasource:board"> > > > > > > > Note that the uniqueKey in Solr is the "id" field. And its value is a > template board-. > I noticed the javadoc comments in DocBuilder#collectDelta it says "Note: In > our definition, unique key of Solr document is the primary key of the top > level entity". This of course isn't really an appropriate assumption. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1230) dataimport.jsp hardcoded to /dataimport handler
[ https://issues.apache.org/jira/browse/SOLR-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721347#action_12721347 ] Noble Paul commented on SOLR-1230: -- yeah, makes sense > dataimport.jsp hardcoded to /dataimport handler > --- > > Key: SOLR-1230 > URL: https://issues.apache.org/jira/browse/SOLR-1230 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: 1.4 > > Attachments: SOLR-1230.patch > > > Currently dataimport.jsp development console only works for a single > /dataimport handler mapping. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1228) NPE thown if a deletedPkQuery returns a row w/o the key
[ https://issues.apache.org/jira/browse/SOLR-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1228. -- Resolution: Fixed committed r785965 > NPE thown if a deletedPkQuery returns a row w/o the key > --- > > Key: SOLR-1228 > URL: https://issues.apache.org/jira/browse/SOLR-1228 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1228.patch > > > see the mail thread > http://markmail.org/thread/3grabel3a6qaqk4e > SEVERE: Delta Import Failed > java.lang.NullPointerException >at > org.apache.solr.handler.dataimport.SolrWriter.deleteDoc(SolrWriter.java:83) >at > org.apache.solr.handler.dataimport.DocBuilder.deleteAll(DocBuilder.java:275) >at > org.apache.solr.handler.dataimport.DocBuilder.doDelta(DocBuilder.java:247) >at > org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:159) >at > org.apache.solr.handler.dataimport.DataImporter.doDeltaImport(DataImporter.java:337) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1226) XPathEntityProcessor should resolve xsl references within Solr's configuration
[ https://issues.apache.org/jira/browse/SOLR-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1226: Assignee: Noble Paul > XPathEntityProcessor should resolve xsl references within Solr's configuration > -- > > Key: SOLR-1226 > URL: https://issues.apache.org/jira/browse/SOLR-1226 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: David Smiley >Assignee: Noble Paul >Priority: Minor > Attachments: SOLR-1226.patch > > > The XPathEntityProcessor forces me to use a URL to specify where my XSL file > is. if it is not a URL, what it should do is attempt to resolve it from > Solr's configuration via SolrCore.getREsourceLoader(). I have attached a > patch which does this. > Note: it is not clear in the DIH what the concurrency model is and thus I was > not certain that XPathEntityProcessor needs to be thread-safe or not. So > just in case I cached the XSLT Transformer in a thread-safe manner using a > ThreadLocal. If DIH committers know that it doesn't have to be thread-safe > then some of this code can be simplified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1228) NPE thown if a deletedPkQuery returns a row w/o the key
NPE thown if a deletedPkQuery returns a row w/o the key --- Key: SOLR-1228 URL: https://issues.apache.org/jira/browse/SOLR-1228 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Priority: Minor Fix For: 1.4 Attachments: SOLR-1228.patch see the mail thread http://markmail.org/thread/3grabel3a6qaqk4e SEVERE: Delta Import Failed java.lang.NullPointerException at org.apache.solr.handler.dataimport.SolrWriter.deleteDoc(SolrWriter.java:83) at org.apache.solr.handler.dataimport.DocBuilder.deleteAll(DocBuilder.java:275) at org.apache.solr.handler.dataimport.DocBuilder.doDelta(DocBuilder.java:247) at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:159) at org.apache.solr.handler.dataimport.DataImporter.doDeltaImport(DataImporter.java:337) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1228) NPE thown if a deletedPkQuery returns a row w/o the key
[ https://issues.apache.org/jira/browse/SOLR-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1228: - Component/s: contrib - DataImportHandler > NPE thown if a deletedPkQuery returns a row w/o the key > --- > > Key: SOLR-1228 > URL: https://issues.apache.org/jira/browse/SOLR-1228 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1228.patch > > > see the mail thread > http://markmail.org/thread/3grabel3a6qaqk4e > SEVERE: Delta Import Failed > java.lang.NullPointerException >at > org.apache.solr.handler.dataimport.SolrWriter.deleteDoc(SolrWriter.java:83) >at > org.apache.solr.handler.dataimport.DocBuilder.deleteAll(DocBuilder.java:275) >at > org.apache.solr.handler.dataimport.DocBuilder.doDelta(DocBuilder.java:247) >at > org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:159) >at > org.apache.solr.handler.dataimport.DataImporter.doDeltaImport(DataImporter.java:337) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1228) NPE thown if a deletedPkQuery returns a row w/o the key
[ https://issues.apache.org/jira/browse/SOLR-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1228: - Attachment: SOLR-1228.patch > NPE thown if a deletedPkQuery returns a row w/o the key > --- > > Key: SOLR-1228 > URL: https://issues.apache.org/jira/browse/SOLR-1228 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1228.patch > > > see the mail thread > http://markmail.org/thread/3grabel3a6qaqk4e > SEVERE: Delta Import Failed > java.lang.NullPointerException >at > org.apache.solr.handler.dataimport.SolrWriter.deleteDoc(SolrWriter.java:83) >at > org.apache.solr.handler.dataimport.DocBuilder.deleteAll(DocBuilder.java:275) >at > org.apache.solr.handler.dataimport.DocBuilder.doDelta(DocBuilder.java:247) >at > org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:159) >at > org.apache.solr.handler.dataimport.DataImporter.doDeltaImport(DataImporter.java:337) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1216) disambiguate the replication command names
[ https://issues.apache.org/jira/browse/SOLR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719922#action_12719922 ] Noble Paul commented on SOLR-1216: -- "image' gives the same idea of snapshot. it suggests that an image of the index exists how about 'fetchIndex' and 'abortfetch' ? > disambiguate the replication command names > -- > > Key: SOLR-1216 > URL: https://issues.apache.org/jira/browse/SOLR-1216 > Project: Solr > Issue Type: Improvement > Components: replication (java) >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1216.patch > > > There is a lot of confusion in the naming of various commands such as > snappull, snapshot etc. This is a vestige of the script based replication we > currently have. The commands can be renamed to make more sense > * 'snappull' to be renamed to 'sync' > * 'snapshot' to be renamed to 'backup' > thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1203) We should add an example of setting the update.processor for a given RequestHandler
[ https://issues.apache.org/jira/browse/SOLR-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719460#action_12719460 ] Noble Paul commented on SOLR-1203: -- update.processor is not for RequestHandler it is common across all requesthandlers > We should add an example of setting the update.processor for a given > RequestHandler > --- > > Key: SOLR-1203 > URL: https://issues.apache.org/jira/browse/SOLR-1203 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > > a commented out example that points to the commented out example update chain -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1216) disambiguate the replication command names
[ https://issues.apache.org/jira/browse/SOLR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1216: - Attachment: SOLR-1216.patch Changes: * 'snappull' renamed to 'sync' * 'abortsnappull' renamed to 'abortsync' *'snapshoot' renamed to 'backup' I shall commit this in a day or two > disambiguate the replication command names > -- > > Key: SOLR-1216 > URL: https://issues.apache.org/jira/browse/SOLR-1216 > Project: Solr > Issue Type: Improvement > Components: replication (java) >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1216.patch > > > There is a lot of confusion in the naming of various commands such as > snappull, snapshot etc. This is a vestige of the script based replication we > currently have. The commands can be renamed to make more sense > * 'snappull' to be renamed to 'sync' > * 'snapshot' to be renamed to 'backup' > thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1214) differentiate between solr home and instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719168#action_12719168 ] Noble Paul commented on SOLR-1214: -- There is no change to solr.xml. Actually there is no external change. This just changes the conventions inside the code. * This deprecates the method SolrResourceLoader#locateInstanceDir() it will be called locateSolrHome * CoreContainer will keep a field solrHome > differentiate between solr home and instanceDir > --- > > Key: SOLR-1214 > URL: https://issues.apache.org/jira/browse/SOLR-1214 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1214.patch > > > There is a lot of confusion on what is an instanceDir in a multicore system. > The CoreContainer must have a field for solrHome and the instanceDir for > each core should be specific to that core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1214) differentiate between solr home and instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719081#action_12719081 ] Noble Paul commented on SOLR-1214: -- I plan to commit this in a day or two. please comment > differentiate between solr home and instanceDir > --- > > Key: SOLR-1214 > URL: https://issues.apache.org/jira/browse/SOLR-1214 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1214.patch > > > There is a lot of confusion on what is an instanceDir in a multicore system. > The CoreContainer must have a field for solrHome and the instanceDir for > each core should be specific to that core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1213) SolrResourceLoader.normalizeDir() should add OS specific file separator
[ https://issues.apache.org/jira/browse/SOLR-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1213. -- Resolution: Fixed committed r783290 > SolrResourceLoader.normalizeDir() should add OS specific file separator > --- > > Key: SOLR-1213 > URL: https://issues.apache.org/jira/browse/SOLR-1213 > Project: Solr > Issue Type: Bug >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1213.patch > > > currently SolrResourceLoader blindly adds "/" irrespective of the OS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1216) disambiguate the replication command names
[ https://issues.apache.org/jira/browse/SOLR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719078#action_12719078 ] Noble Paul commented on SOLR-1216: -- bq.Lets also clearup the doc for this stuff as part of the issue yes the wiki has to be cleaned up too bq.Are backups made in the same format as the scripts method The format is same (same dir name format). The mechanism is different. scripts use hard links , this uses copying bq.Is it possible to replicate a backup or just the live index? nope. only live index can be transferred. The backup can be made the live index and then the user can replicate it. There is a file called index.properties in the dataDir (only created by replicationhandler. but users can create them too ). It can take a property index= which tells solr core where to load the index from. users can edit that and do a reload core for the new backup to be used as the index. bq.what happens when you shutdown during a replication - does Solr wait? Abort? If its aborts, are the temp files cleaned up later? replication is aborted. temp files will remain as is. They will not be cleaned up automatically. But presence of those temp files will not have any impact of future replication. bq.replicate and polling both to default to on right? yes bq.and the replicate setting just stops any slaves hitting a master with replicate=off from syncing? the slaves will keep polling even if the master has disabled replication . But the master will respond with "no changes" .This will ensure that when the replication is re-enabled from master , the slaves will be able to resume replication > disambiguate the replication command names > -- > > Key: SOLR-1216 > URL: https://issues.apache.org/jira/browse/SOLR-1216 > Project: Solr > Issue Type: Improvement > Components: replication (java) >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > > There is a lot of confusion in the naming of various commands such as > snappull, snapshot etc. This is a vestige of the script based replication we > currently have. The commands can be renamed to make more sense > * 'snappull' to be renamed to 'sync' > * 'snapshot' to be renamed to 'backup' > thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1216) disambiguate the replication command names
[ https://issues.apache.org/jira/browse/SOLR-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718713#action_12718713 ] Noble Paul commented on SOLR-1216: -- the relevant mail thread http://markmail.org/thread/zucdwx4p2xmeaejj > disambiguate the replication command names > -- > > Key: SOLR-1216 > URL: https://issues.apache.org/jira/browse/SOLR-1216 > Project: Solr > Issue Type: Improvement > Components: replication (java) >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > > There is a lot of confusion in the naming of various commands such as > snappull, snapshot etc. This is a vestige of the script based replication we > currently have. The commands can be renamed to make more sense > * 'snappull' to be renamed to 'sync' > * 'snapshot' to be renamed to 'backup' > thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1216) disambiguate the replication command names
disambiguate the replication command names -- Key: SOLR-1216 URL: https://issues.apache.org/jira/browse/SOLR-1216 Project: Solr Issue Type: Improvement Components: replication (java) Reporter: Noble Paul Assignee: Noble Paul Fix For: 1.4 There is a lot of confusion in the naming of various commands such as snappull, snapshot etc. This is a vestige of the script based replication we currently have. The commands can be renamed to make more sense * 'snappull' to be renamed to 'sync' * 'snapshot' to be renamed to 'backup' thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1214) differentiate between solr home and instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1214: - Attachment: SOLR-1214.patch * the locateInstanceDir is deprecated. it is renamed to locateSolrHome * The instanceDir is same as solrhome for a single core solr . For multicore there is no real relationship with solrhome and instancedir of a core. > differentiate between solr home and instanceDir > --- > > Key: SOLR-1214 > URL: https://issues.apache.org/jira/browse/SOLR-1214 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1214.patch > > > There is a lot of confusion on what is an instanceDir in a multicore system. > The CoreContainer must have a field for solrHome and the instanceDir for > each core should be specific to that core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1215) use double quote to enclose attributes in solr.xml
[ https://issues.apache.org/jira/browse/SOLR-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1215. -- Resolution: Fixed committed r783715 > use double quote to enclose attributes in solr.xml > -- > > Key: SOLR-1215 > URL: https://issues.apache.org/jira/browse/SOLR-1215 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1215.patch > > > the sample solr.xml has attributes wrapped in double quotes. But when it is > persisted back , it is wrapped in single duote. > for consistency let us persist it in double quotes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1215) use double quote to enclose attributes in solr.xml
[ https://issues.apache.org/jira/browse/SOLR-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1215: - Attachment: SOLR-1215.patch the fix > use double quote to enclose attributes in solr.xml > -- > > Key: SOLR-1215 > URL: https://issues.apache.org/jira/browse/SOLR-1215 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1215.patch > > > the sample solr.xml has attributes wrapped in double quotes. But when it is > persisted back , it is wrapped in single duote. > for consistency let us persist it in double quotes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1215) use double quote to enclose attributes in solr.xml
use double quote to enclose attributes in solr.xml -- Key: SOLR-1215 URL: https://issues.apache.org/jira/browse/SOLR-1215 Project: Solr Issue Type: Improvement Reporter: Noble Paul Assignee: Noble Paul Priority: Minor Fix For: 1.4 the sample solr.xml has attributes wrapped in double quotes. But when it is persisted back , it is wrapped in single duote. for consistency let us persist it in double quotes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1120) Simplify EntityProcessor API
[ https://issues.apache.org/jira/browse/SOLR-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1120: - Attachment: SOLR-1120.patch a new method added to EntityProcessor (postTransform) . this can be used by the EntityProcessor implementations to get a callback after the transformations are done > Simplify EntityProcessor API > > > Key: SOLR-1120 > URL: https://issues.apache.org/jira/browse/SOLR-1120 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, > SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, > SOLR-1120.patch, SOLR-1120.patch > > > Writing an EntityProcessor is deceptively complex. There are so many gotchas. > I propose the following: > # Extract out the Transformer application logic from EntityProcessor and add > it to DocBuilder. Then EntityProcessor do not need to call applyTransformer > or know about rowIterator and getFromRowCache() methods. > # Change the meaning of EntityProcessor#destroy to be called on end of > parent's row -- Right now init is called once per parent row but destroy > actually means the end of import. In fact, there is no correct way for an > entity processor to do clean up right now. Most do clean up when returning > null (end of data) but with the introduction of $skipDoc, a transformer can > return $skipDoc and the entity processor will never get a chance to clean up > for the current init. > # EntityProcessor will use the EventListener API to listen for import end. > This should be used by EntityProcessor to do a final cleanup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-920) Cache and reuse IndexSchema
[ https://issues.apache.org/jira/browse/SOLR-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718299#action_12718299 ] Noble Paul commented on SOLR-920: - committed :r783631 > Cache and reuse IndexSchema > --- > > Key: SOLR-920 > URL: https://issues.apache.org/jira/browse/SOLR-920 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-920.patch, SOLR-920.patch, SOLR-920.patch > > > if there are 1000's of cores then the cost of loading unloading schema.xml > can be prohibitive > similar to SOLR-919 we can also cache the DOM object of schema.xml if the > location on disk is same. All the dynamic properties can be replaced lazily > when they are read. > We can go one step ahead in this case. Th IndexSchema object is immutable . > So if there are no core properties then the same IndexSchema object can be > used across all the cores -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-920) Cache and reuse IndexSchema
[ https://issues.apache.org/jira/browse/SOLR-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-920: Attachment: SOLR-920.patch logging that re-use is done and the path is made right > Cache and reuse IndexSchema > --- > > Key: SOLR-920 > URL: https://issues.apache.org/jira/browse/SOLR-920 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-920.patch, SOLR-920.patch, SOLR-920.patch > > > if there are 1000's of cores then the cost of loading unloading schema.xml > can be prohibitive > similar to SOLR-919 we can also cache the DOM object of schema.xml if the > location on disk is same. All the dynamic properties can be replaced lazily > when they are read. > We can go one step ahead in this case. Th IndexSchema object is immutable . > So if there are no core properties then the same IndexSchema object can be > used across all the cores -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1214) differentiate between solr home and instanceDir
differentiate between solr home and instanceDir --- Key: SOLR-1214 URL: https://issues.apache.org/jira/browse/SOLR-1214 Project: Solr Issue Type: Improvement Reporter: Noble Paul Assignee: Noble Paul Fix For: 1.4 There is a lot of confusion on what is an instanceDir in a multicore system. The CoreContainer must have a field for solrHome and the instanceDir for each core should be specific to that core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1213) SolrResourceLoader.normalizeDir() should add OS specific file separator
[ https://issues.apache.org/jira/browse/SOLR-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1213: - Attachment: SOLR-1213.patch the fix. > SolrResourceLoader.normalizeDir() should add OS specific file separator > --- > > Key: SOLR-1213 > URL: https://issues.apache.org/jira/browse/SOLR-1213 > Project: Solr > Issue Type: Bug >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1213.patch > > > currently SolrResourceLoader blindly adds "/" irrespective of the OS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1213) SolrResourceLoader.normalizeDir() should add OS specific file separator
[ https://issues.apache.org/jira/browse/SOLR-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1213: Assignee: Noble Paul > SolrResourceLoader.normalizeDir() should add OS specific file separator > --- > > Key: SOLR-1213 > URL: https://issues.apache.org/jira/browse/SOLR-1213 > Project: Solr > Issue Type: Bug >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Trivial > Fix For: 1.4 > > > currently SolrResourceLoader blindly adds "/" irrespective of the OS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1213) SolrResourceLoader.normalizeDir() should add OS specific file separator
SolrResourceLoader.normalizeDir() should add OS specific file separator --- Key: SOLR-1213 URL: https://issues.apache.org/jira/browse/SOLR-1213 Project: Solr Issue Type: Bug Reporter: Noble Paul Priority: Trivial Fix For: 1.4 currently SolrResourceLoader blindly adds "/" irrespective of the OS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1198: - Attachment: SOLR-1198.patch moved highlighter > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, > SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717937#action_12717937 ] Noble Paul commented on SOLR-1198: -- committed r783222 > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, > SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1161) Exception in TestLBHttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1161. -- Resolution: Fixed mark checked in the changes in Revision: 782658 let us reopen this if it is observed again > Exception in TestLBHttpSolrServer > - > > Key: SOLR-1161 > URL: https://issues.apache.org/jira/browse/SOLR-1161 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > > Just ran into this in testTwoServers - been running the tests pretty much all > day and just randomly hit it: > org.apache.solr.client.solrj.SolrServerException: Error executing query > at > org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:96) > at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:113) > at > org.apache.solr.client.solrj.TestLBHttpSolrServer.testTwoServers(TestLBHttpSolrServer.java:140) > Caused by: org.apache.solr.common.SolrException: parsing error > at > org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(BinaryResponseParser.java:41) > at > org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:467) > at > org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:242) > at > org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:205) > at > org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90) > Caused by: java.io.IOException: Stream closed > at > java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:162) > at java.io.BufferedInputStream.read(BufferedInputStream.java:325) > at > org.apache.commons.httpclient.ContentLengthInputStream.read(ContentLengthInputStream.java:170) > at java.io.FilterInputStream.read(FilterInputStream.java:133) > at > org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInputStream.java:108) > at > org.apache.solr.common.util.FastInputStream.refill(FastInputStream.java:68) > at > org.apache.solr.common.util.FastInputStream.readByte(FastInputStream.java:159) > at > org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:96) > at > org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(BinaryResponseParser.java:39) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1208) The Default SearchComponents (QueryComponent, etc.) cannot currently support SolrCoreAware or ResourceLoaderAware
[ https://issues.apache.org/jira/browse/SOLR-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717617#action_12717617 ] Noble Paul commented on SOLR-1208: -- It is most likely fixed in the trunk as part of SOLR-1198 in r782913 > The Default SearchComponents (QueryComponent, etc.) cannot currently support > SolrCoreAware or ResourceLoaderAware > - > > Key: SOLR-1208 > URL: https://issues.apache.org/jira/browse/SOLR-1208 > Project: Solr > Issue Type: Bug >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > > The Default SearchComponents are not instantiated via the SolrResourceLoader > and are thus not put in the waiting lists for SolrCoreAware and > ResourceLoaderAware. Thus, they are not constructed in the same that other > SearchComponents might be constructed. > See > http://www.lucidimagination.com/search/document/ef69fdc7dfb17428/default_searchcomponents_and_solrcoreaware -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1198: - Attachment: SOLR-1198.patch moved searchComponent, indexReaderFactory > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, > SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717614#action_12717614 ] Noble Paul commented on SOLR-1198: -- committed r782913 > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, > SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717571#action_12717571 ] Noble Paul commented on SOLR-1198: -- committed r782885 > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, > SOLR-1198.patch, SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1198: - Attachment: SOLR-1198.patch moved updateHandler, updateprocessor to solrconfig > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, > SOLR-1198.patch, SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SOLR-1120) Simplify EntityProcessor API
[ https://issues.apache.org/jira/browse/SOLR-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reopened SOLR-1120: -- this has broken some features in XPathEntityProcessor if a field is added by a transformer then XPathEntityProcessor is unable to use it in common fields .Features like $nextUrl , $hasMore cannot work > Simplify EntityProcessor API > > > Key: SOLR-1120 > URL: https://issues.apache.org/jira/browse/SOLR-1120 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, > SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, > SOLR-1120.patch > > > Writing an EntityProcessor is deceptively complex. There are so many gotchas. > I propose the following: > # Extract out the Transformer application logic from EntityProcessor and add > it to DocBuilder. Then EntityProcessor do not need to call applyTransformer > or know about rowIterator and getFromRowCache() methods. > # Change the meaning of EntityProcessor#destroy to be called on end of > parent's row -- Right now init is called once per parent row but destroy > actually means the end of import. In fact, there is no correct way for an > entity processor to do clean up right now. Most do clean up when returning > null (end of data) but with the introduction of $skipDoc, a transformer can > return $skipDoc and the entity processor will never get a chance to clean up > for the current init. > # EntityProcessor will use the EventListener API to listen for import end. > This should be used by EntityProcessor to do a final cleanup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717197#action_12717197 ] Noble Paul commented on SOLR-1198: -- committed : r782552 > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, > SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1198: - Attachment: SOLR-1198.patch moved valueSourceParser, listeners, deletionPolicy,directoryFactory,queryParser,responseWriter, I shall commit this shortly > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, > SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716863#action_12716863 ] Noble Paul commented on SOLR-1198: -- committed revision: 782219 > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1198: - Attachment: SOLR-1198.patch tested. I'll commit this shortly > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1205) add a field alias feature
[
https://issues.apache.org/jira/browse/SOLR-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716653#action_12716653
]
Noble Paul commented on SOLR-1205:
--
bq.Am I the only person who finds that {!foo=bar} syntax very hard to parse and
understand?
Otis, you are not alone. The localparams syntax is hard to understand.It is ok
for the purpose it serves . But I don't think we need that syntax for this
usecase.
> add a field alias feature
> -
>
> Key: SOLR-1205
> URL: https://issues.apache.org/jira/browse/SOLR-1205
> Project: Solr
> Issue Type: New Feature
>Reporter: Noble Paul
> Fix For: 1.5
>
>
> A feature which is similar to the SQL 'as' can be helpful
> see the mail thread
> http://www.lucidimagination.com/search/document/63b63edc15092922/customizing_results#63b63edc15092922
> it can be implemented as a separate request param
> say
> {code}
> fl.alias=from_name1:to_name1&fl.alias=from_name2:to_name2
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1205) add a field alias feature
[
https://issues.apache.org/jira/browse/SOLR-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716568#action_12716568
]
Noble Paul commented on SOLR-1205:
--
bq.However a simple XSLT transform on the search output using..
The problem is that it would not help if you are using json/javabin/phps output
formats and we cannot propose it as a solution
just the opposite
{code}
fl.alias=placename:title&fl.alias=subject:title
{code}
This will have no impact on the query.(just like the fl parameter) . if just
renames the fields in the result docs
> add a field alias feature
> -
>
> Key: SOLR-1205
> URL: https://issues.apache.org/jira/browse/SOLR-1205
> Project: Solr
> Issue Type: New Feature
>Reporter: Noble Paul
> Fix For: 1.5
>
>
> A feature which is similar to the SQL 'as' can be helpful
> see the mail thread
> http://www.lucidimagination.com/search/document/63b63edc15092922/customizing_results#63b63edc15092922
> it can be implemented as a separate request param
> say
> {code}
> fl.alias=from_name1:to_name1&fl.alias=from_name2:to_name2
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1205) add a field alias feature
add a field alias feature
-
Key: SOLR-1205
URL: https://issues.apache.org/jira/browse/SOLR-1205
Project: Solr
Issue Type: New Feature
Reporter: Noble Paul
Fix For: 1.5
A feature which is similar to the SQL 'as' can be helpful
see the mail thread
http://www.lucidimagination.com/search/document/63b63edc15092922/customizing_results#63b63edc15092922
it can be implemented as a separate request param
say
{code}
fl.alias=from_name1:to_name1&fl.alias=from_name2:to_name2
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1186) parentdeltaQuery invoked on wrong entity
[ https://issues.apache.org/jira/browse/SOLR-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1186. -- Resolution: Fixed committed revision :781925 > parentdeltaQuery invoked on wrong entity > > > Key: SOLR-1186 > URL: https://issues.apache.org/jira/browse/SOLR-1186 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1186.patch > > > The nextModifiedParentRowKey() is invoked on the wrong entity by DIH. This > means that that attribute does not work at all -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1197) memcached implement solr cache for queryresultCache
[ https://issues.apache.org/jira/browse/SOLR-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1197: Assignee: Noble Paul > memcached implement solr cache for queryresultCache > > > Key: SOLR-1197 > URL: https://issues.apache.org/jira/browse/SOLR-1197 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 > Environment: multiple slave solr replication environment >Reporter: Linbin Chen >Assignee: Noble Paul > Fix For: 1.5 > > Attachments: SOLR_1197-solr-memcache.patch > > > multiple slave create query result together, and slaves can share that. > implement memcached cache instead LRUCache > my implement: > solr-memcache.zip http://solr-side.googlecode.com/files/solr-memcache.zip > object transport by net need Serializable, so need patch solr 1.3, DocSetBase > implements Serializable, see > http://code.google.com/p/solr-side/issues/detail?id=1&can=1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1197) memcached implement solr cache for queryresultCache
[ https://issues.apache.org/jira/browse/SOLR-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1197: - Fix Version/s: (was: 1.4) 1.5 moving to 1.5. it is not a good idea to accept new features for 1.4 > memcached implement solr cache for queryresultCache > > > Key: SOLR-1197 > URL: https://issues.apache.org/jira/browse/SOLR-1197 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 > Environment: multiple slave solr replication environment >Reporter: Linbin Chen > Fix For: 1.5 > > Attachments: SOLR_1197-solr-memcache.patch > > > multiple slave create query result together, and slaves can share that. > implement memcached cache instead LRUCache > my implement: > solr-memcache.zip http://solr-side.googlecode.com/files/solr-memcache.zip > object transport by net need Serializable, so need patch solr 1.3, DocSetBase > implements Serializable, see > http://code.google.com/p/solr-side/issues/detail?id=1&can=1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1161) Exception in TestLBHttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1161: Assignee: Noble Paul > Exception in TestLBHttpSolrServer > - > > Key: SOLR-1161 > URL: https://issues.apache.org/jira/browse/SOLR-1161 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > > Just ran into this in testTwoServers - been running the tests pretty much all > day and just randomly hit it: > org.apache.solr.client.solrj.SolrServerException: Error executing query > at > org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:96) > at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:113) > at > org.apache.solr.client.solrj.TestLBHttpSolrServer.testTwoServers(TestLBHttpSolrServer.java:140) > Caused by: org.apache.solr.common.SolrException: parsing error > at > org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(BinaryResponseParser.java:41) > at > org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:467) > at > org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:242) > at > org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:205) > at > org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90) > Caused by: java.io.IOException: Stream closed > at > java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:162) > at java.io.BufferedInputStream.read(BufferedInputStream.java:325) > at > org.apache.commons.httpclient.ContentLengthInputStream.read(ContentLengthInputStream.java:170) > at java.io.FilterInputStream.read(FilterInputStream.java:133) > at > org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInputStream.java:108) > at > org.apache.solr.common.util.FastInputStream.refill(FastInputStream.java:68) > at > org.apache.solr.common.util.FastInputStream.readByte(FastInputStream.java:159) > at > org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:96) > at > org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(BinaryResponseParser.java:39) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1144) replication hang
[ https://issues.apache.org/jira/browse/SOLR-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1144. -- Resolution: Fixed resolving for the time being. We can reopen if the issue is reported again > replication hang > > > Key: SOLR-1144 > URL: https://issues.apache.org/jira/browse/SOLR-1144 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Assignee: Noble Paul > Fix For: 1.4 > > > It seems that replication can sometimes hang. > http://www.lucidimagination.com/search/document/403305a3fda18599 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1144) replication hang
[ https://issues.apache.org/jira/browse/SOLR-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1144: Assignee: Noble Paul > replication hang > > > Key: SOLR-1144 > URL: https://issues.apache.org/jira/browse/SOLR-1144 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Assignee: Noble Paul > Fix For: 1.4 > > > It seems that replication can sometimes hang. > http://www.lucidimagination.com/search/document/403305a3fda18599 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1129) SolrJ cannot bind dynamic fields to beans
[
https://issues.apache.org/jira/browse/SOLR-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1129:
-
Attachment: SOLR-1129.patch
w/o the SOPs
> SolrJ cannot bind dynamic fields to beans
> -
>
> Key: SOLR-1129
> URL: https://issues.apache.org/jira/browse/SOLR-1129
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 1.3
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1129.patch, SOLR-1129.patch, SOLR-1129.patch,
> SOLR-1129.patch, SOLR-1129.patch
>
>
> SolrJ does not support binding of dynamic fields to bean fields
> The field declaration could be as follows
> {code:java}
> @Field("*_s")
> public String anyString;
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1129) SolrJ cannot bind dynamic fields to beans
[
https://issues.apache.org/jira/browse/SOLR-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1129:
-
Attachment: SOLR-1129.patch
My attempt at simplifying the patch .
pleas take a look and let me know if any usecase is missing
> SolrJ cannot bind dynamic fields to beans
> -
>
> Key: SOLR-1129
> URL: https://issues.apache.org/jira/browse/SOLR-1129
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 1.3
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1129.patch, SOLR-1129.patch, SOLR-1129.patch,
> SOLR-1129.patch
>
>
> SolrJ does not support binding of dynamic fields to bean fields
> The field declaration could be as follows
> {code:java}
> @Field("*_s")
> public String anyString;
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1198: - Attachment: SOLR-1198.patch This moves the RequestHandler xml parsing to SolrConfig. This introduces a class PluginInfo which can be used for all pluggable classes > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch, SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716260#action_12716260 ] Noble Paul commented on SOLR-1198: -- comitted revision : 781668 with unlockOnStartup, useColdSearcher, maxWarmingSearchers moved to SolrConfig > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1200) NullPointerException when unloading an absent core
[ https://issues.apache.org/jira/browse/SOLR-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716255#action_12716255 ] Noble Paul commented on SOLR-1200: -- If a core does not exist 'unload'ing that core is not possible . So it is an error. For status command. it would be better to return "no such core exists" > NullPointerException when unloading an absent core > -- > > Key: SOLR-1200 > URL: https://issues.apache.org/jira/browse/SOLR-1200 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 > Environment: java version "1.6.0_07" >Reporter: Peter Wolanin >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1200.patch, SOLR-1200.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > When I try to unload a core that does not exist (e.g. it has already been > unloaded), Solr throws a NullPointerException > java.lang.NullPointerException >at > org.apache.solr.handler.admin.CoreAdminHandler.handleUnloadAction(CoreAdminHandler.java:319) >at > org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:125) >at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) >at > org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:301) >at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:174) >at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) >at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1198: - Attachment: SOLR-1198.patch this issue can be fixed in batches. this is one low hanging fruit > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1198: Assignee: Noble Paul > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1200) NullPointerException when unloading an absent core
[ https://issues.apache.org/jira/browse/SOLR-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1200. -- Resolution: Fixed Fix Version/s: 1.4 committed revision: 781656 > NullPointerException when unloading an absent core > -- > > Key: SOLR-1200 > URL: https://issues.apache.org/jira/browse/SOLR-1200 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 > Environment: java version "1.6.0_07" >Reporter: Peter Wolanin >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1200.patch, SOLR-1200.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > When I try to unload a core that does not exist (e.g. it has already been > unloaded), Solr throws a NullPointerException > java.lang.NullPointerException >at > org.apache.solr.handler.admin.CoreAdminHandler.handleUnloadAction(CoreAdminHandler.java:319) >at > org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:125) >at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) >at > org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:301) >at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:174) >at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) >at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1200) NullPointerException when unloading an absent core
[ https://issues.apache.org/jira/browse/SOLR-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1200: - Attachment: SOLR-1200.patch it should throw an exception if the core does not exist > NullPointerException when unloading an absent core > -- > > Key: SOLR-1200 > URL: https://issues.apache.org/jira/browse/SOLR-1200 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 > Environment: java version "1.6.0_07" >Reporter: Peter Wolanin >Assignee: Noble Paul >Priority: Minor > Attachments: SOLR-1200.patch, SOLR-1200.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > When I try to unload a core that does not exist (e.g. it has already been > unloaded), Solr throws a NullPointerException > java.lang.NullPointerException >at > org.apache.solr.handler.admin.CoreAdminHandler.handleUnloadAction(CoreAdminHandler.java:319) >at > org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:125) >at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) >at > org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:301) >at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:174) >at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) >at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1200) NullPointerException when unloading an absent core
[ https://issues.apache.org/jira/browse/SOLR-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1200: Assignee: Noble Paul > NullPointerException when unloading an absent core > -- > > Key: SOLR-1200 > URL: https://issues.apache.org/jira/browse/SOLR-1200 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 > Environment: java version "1.6.0_07" >Reporter: Peter Wolanin >Assignee: Noble Paul >Priority: Minor > Attachments: SOLR-1200.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > When I try to unload a core that does not exist (e.g. it has already been > unloaded), Solr throws a NullPointerException > java.lang.NullPointerException >at > org.apache.solr.handler.admin.CoreAdminHandler.handleUnloadAction(CoreAdminHandler.java:319) >at > org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:125) >at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) >at > org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:301) >at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:174) >at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) >at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1051) Support the merge of multiple indexes
[ https://issues.apache.org/jira/browse/SOLR-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716167#action_12716167 ] Noble Paul edited comment on SOLR-1051 at 6/3/09 11:15 PM: --- A few suggestions: * There should be a provision to merge one core w/ another. According to me the most common usecase would be to create a core , add docs to that , and then just merge it into the main core which is serving requests. This way, the user will not need to touch the filesystem of directly. * The indexDirs parameter should not be comma separated values. http request can accept multiple values for same parameter was (Author: noble.paul): A few suggestions: * There should be a provision to merge one core w/ another. According to me this is the most common usecase would be to create a core add docs to that , and when I am done I just merge it into the main core which is serving requests. This way I will not need to touch the filesystem of directly . * The indexDirs parameter should not be comma separated values. http can accept multiple values for same parameter > Support the merge of multiple indexes > - > > Key: SOLR-1051 > URL: https://issues.apache.org/jira/browse/SOLR-1051 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Ning Li >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1051.patch, SOLR-1051.patch, SOLR-1051.patch > > > This is to support the merge of multiple indexes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
