[
https://issues.apache.org/jira/browse/METRON-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16083109#comment-16083109
]
ASF GitHub Bot commented on METRON-1030:
----------------------------------------
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/646
Here's the challenge with all this. Maybe we can collaborate on the right
approach.
The REST app requires a relational database and setting that up is a
prerequisite, unless you want to use h2. We can provide a way to automatically
run a script and make this setup easier (we do that for h2 and mysql). But
it's likely that different orgs will want to use their own database and we
probably don't want to try and maintain scripts for every possible database out
there.
So what's the best approach? Do we:
- Remove the convenience scripts and document setup as best we can (again
providing the exact SQL statements for every database is not feasible). In
this case we would just remove this metron_jdbc_platform property from Ambari
because it's not needed anymore.
- Limit our database support to a handful of databases and provide setup
scripts for those? In this case the metron_jdbc_platform could be a dropdown
with the databases we support but users would be forced to use one of those.
- Keep it like it is now, provide a convenient way to initialize MySQL with
other databases requiring manual setup. In this case metron_jdbc_platform
would accept h2, mysql, or empty meaning the user is responsible for setup.
Either way, the READMEs need to be improved which probably includes moving
this database setup prerequisite to a higher level so that it's more obvious
and providing more detail around manual setup.
> Metron JDBC platform REST option should accept a blank value
> ------------------------------------------------------------
>
> Key: METRON-1030
> URL: https://issues.apache.org/jira/browse/METRON-1030
> Project: Metron
> Issue Type: Bug
> Reporter: Ryan Merriman
> Assignee: Ryan Merriman
>
> We should be able to set this property to a blank string
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
