You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Noble Paul (JIRA)" <ji...@apache.org> on 2009/07/18 07:48:14 UTC
[jira] Commented: (SOLR-1262) DIH needs support for prepared
statements
[ https://issues.apache.org/jira/browse/SOLR-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732846#action_12732846 ]
Noble Paul commented on SOLR-1262:
----------------------------------
do you mean prepared statement or callablestatement (stored procedures)? . I guess there is not much difference between the semantics of prepared statements and sql statements
> DIH needs support for prepared statements
> ------------------------------------------
>
> Key: SOLR-1262
> URL: https://issues.apache.org/jira/browse/SOLR-1262
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
> Affects Versions: 1.3
> Environment: linux
> mysql
> Reporter: Abdul Chaudhry
> Assignee: Noble Paul
> Priority: Minor
>
> During an indexing run we noticed that we were spending a lot of time creating and tearing down queries in mysql
> The queries we are using are complex and involve joins spanning across multiple tables.
> We should support prepared statements in the data import handler via the data-config.xml file - for those databases that support prepared statements.
> We could add a new attribute to the entity entity in dataConfig - say - pquery or preparedQuery and then pass the prepared statement and have values filled in by the actual queries for each row using a placeholder - like a ? or something else.
> I would probably start by hacking class JdbcDataSource to try a test but was wondering if anyone had experienced this or had any suggestions or if there is something in the works that I missed - I couldn't find any other bugs mentioning using prepared statements for performance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.