[
https://issues.apache.org/jira/browse/SOLR-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608421#action_12608421
]
Grant Ingersoll commented on SOLR-469:
--------------------------------------
Patch applies cleanly, tests pass, although I notice several @ignore in there.
Docs look good in my preliminary perusing. I've only started looking at
things, and have a lot of reading to catch up on, so these first comments,
please take with a grain of salt, as the English saying goes...
I'd suggest,that instead of relying on MySQL in TestJdbcDataSource, we instead
use and embedded Derby or some sort of JDBC mock. I suggest Derby mainly b/c
it's already ASF and I don't want to bother looking up licenses for HSQL or any
of the others that might work.
Also, I notice several interfaces that have a number of methods on them. Have
you thought about abstract base classes instead? I know, there is a whole big
debate over it, and people will argue that if you get the interface exactly
correct, you should use interfaces. Nice in theory, but Lucene/Solr experience
suggests that rarely happens. Of course, I think the correct way is to
actually do both, as one can easily decorate an abstract base class with more
interfaces as needed. Just food for thought, b/c what's going to quickly
happen after release is someone is going to need a new method on the DataSource
or something and then we are going to be stuck doing all kinds of workarounds
due to back compatibility reasons. The alternative is to clearly mark all
Interfaces as being experimental at this point and clearly note that we expect
them to change. We may even want to consider both! The other point, though,
is contrib packages need not be held to the same standard as core when it comes
to back compat.
What relation does the Context have to the HttpDataSource? In other words, the
DataSource init method takes a Context, meaning the HttpDataSource needs a
Context, yet in my first glance at the Context, it seems to be DB related.
What if I wanted to slurp from a table on the fly? That is, I want to send in
a select statement in my request and I let the columns line up where they may
Field wise (i.e. via dynamic fields or I rely on something like select id, colA
as fieldA, colB as fieldB from MyTable; )
Is that possible?
Interactive mode has a bit of a chicken and the egg problem when it comes to
JDBC, right, in that the Driver needs to be present in Solr/lib right? So, one
can currently only interactively configure a JDBC DataSource if the driver is
already in lib and loaded by the ClassLoader. If you haven't already, it
might actually be useful to show what drivers are present by using the
DriverManager.
In the JDBCDataSource, not sure I follow the connection stuff. Can you explain
a bit? Also, what if I wanted to plug in my own Connection Pooling library, as
I may already have one setup for other things (if using Solr embedded)?
> Data Import RequestHandler
> --------------------------
>
> Key: SOLR-469
> URL: https://issues.apache.org/jira/browse/SOLR-469
> Project: Solr
> Issue Type: New Feature
> Components: update
> Affects Versions: 1.3
> Reporter: Noble Paul
> Assignee: Grant Ingersoll
> Fix For: 1.3
>
> Attachments: SOLR-469-contrib.patch, SOLR-469-contrib.patch,
> SOLR-469-contrib.patch, SOLR-469-contrib.patch, SOLR-469-contrib.patch,
> SOLR-469-contrib.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch,
> SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch,
> SOLR-469.patch, SOLR-469.patch
>
>
> We need a RequestHandler Which can import data from a DB or other dataSources
> into the Solr index .Think of it as an advanced form of SqlUpload Plugin
> (SOLR-103).
> The way it works is as follows.
> * Provide a configuration file (xml) to the Handler which takes in the
> necessary SQL queries and mappings to a solr schema
> - It also takes in a properties file for the data source
> configuraution
> * Given the configuration it can also generate the solr schema.xml
> * It is registered as a RequestHandler which can take two commands
> do-full-import, do-delta-import
> - do-full-import - dumps all the data from the Database into the
> index (based on the SQL query in configuration)
> - do-delta-import - dumps all the data that has changed since last
> import. (We assume a modified-timestamp column in tables)
> * It provides a admin page
> - where we can schedule it to be run automatically at regular
> intervals
> - It shows the status of the Handler (idle, full-import,
> delta-import)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
