[
https://issues.apache.org/jira/browse/TIKA-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275534#comment-14275534
]
Tim Allison edited comment on TIKA-1511 at 1/13/15 5:04 PM:
------------------------------------------------------------
Looks like we're cleared via LEGAL-215 for xerial or anything else that wraps
sqlite. We can add some language about the underlying sqlite non-license and
we should be good to go.
I think my preference for now would be to have an abstract base class (with at
least these abstract methods: getConnection(), getTableNames(),
addMetadata(Connection connection, Metadata metadata), close(Connection
connection)) that we can extend for each db parser. The abstract class would
implement the "select * from eachtable". This plan would only work for
jdbc-compliant-ish dependencies that can return a Connection. It appears that
this plan would work for xerial but not for sqlite4java...that said, I'm not
above writing a separate parser for db-specific calls as with sqlite4java's
SQLiteConnection. :)
I defer to the community on whether to go this route, the ManifoldCF route or
another.
As [~grossws] recommended, we can build the parsers and then do a check for
whether or not the drivers are available. The user would be responsible for
adding any non Apache licensable jars to their classpath.
was (Author: [email protected]):
Looks like we're cleared via LEGAL-215 for xerial or anything else that wraps
sqlite. We can add some language about the underlying sqlite non-license and
we should be good to go.
I think my preference for now would be to have an abstract base class (with at
least these abstract methods: getConnection(), getTableNames(),
addMetadata(Connection connection, Metadata metadata), close(Connection
connection) that we can extend for each db parser. The abstract class would
implement the "select * from eachtable". This plan would only work for
jdbc-compliant dependencies that can return a Connection. It appears that this
plan would work for xerial but not for sqlite4java...that said, I'm not above
writing a separate parser for db-specific calls as with sqlite4java's
SQLiteConnection. :)
I defer to the community on whether to go this route, the ManifoldCF route or
another.
As [~grossws] recommended, we can build the parsers and then do a check for
whether or not the drivers are available. The user would be responsible for
adding any non Apache licensable jars to their classpath.
> Create a parser for SQLite3
> ---------------------------
>
> Key: TIKA-1511
> URL: https://issues.apache.org/jira/browse/TIKA-1511
> Project: Tika
> Issue Type: New Feature
> Components: parser
> Affects Versions: 1.6
> Reporter: Luis Filipe Nassif
> Fix For: 1.8
>
>
> I think it would be very useful, as sqlite is used as data storage by a wide
> range of applications. Opening the ticket to track it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
