Kudos for the database plugin Kohsuke :-)
>- I want to create a global Database instance that's available to
> plugins for use. I think some plugins would find such a storage
> useful, and I think it's better for the admin to configure it once
> and let all interested plugins use it, as opposed to every plugin
> coming up with its own places to store stuff.
+1
>- I want to also create a per-job file-backed embedded Database
> instance that plugins can use to store job-scoped stuff (like test
> reports and analysis results.)
+1 as well, I would like to give it a try in TAP Plug-in [1].
>name collisions of tables among different plugins
Maybe we could prepend the plugin groupId+artifactId, or similar mechanism? But
transparent to the plug-in developer. So that from testlink-plugin I could have
a table "tests", that would be stored in the global database as something like
org.jenkins-ci.plugins.testlink.tests, but referenced in my code as simply
tests.
>how schemas kept in sync with plugin versions
Maybe using liquibase (Tony França's is going to talk about it [2]), or some
other migration framework for Java? And maybe give the option to use a
different schema?
>Are these interesting? Would any plugin developers interested in using this?
>Any suggestion for abstraction improvements before I release the first version
>of the plugin?
Besides TAP Plug-in, I would like to try using this database with the static
analysis plug-ins. NDepend [3] has an interesting feature, CQLinq [4], that
lets you "query for metrics". So you can do something like:
Query for the top 10 most complex methods
(from m in Methods
orderby m.CyclomaticComplexity
select new { m, m.CyclomaticComplexity }).Take(10)
Using a database in the static analysis plug-ins, we could expose a "Metrics
Query" (I'm horrible creating names, sorry), that would let users query for the
metrics. We could add filters to the queries too, like per project, per job,
per build, etc.
So I could, for example, get the top 10 projects with lowest coverage, using
SQL (maybe in the future we could add a pre-process and use a higher level
query language). Something like:
SELECT TOP 10 coverage
What do you think?
[1] https://wiki.jenkins-ci.org/display/JENKINS/TAP+Plugin
[2] http://www.meetup.com/jenkinsmeetup/events/91744672/
[3] http://www.ndepend.com/
[4] http://www.ndepend.com/Features.aspx#CQL
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com
>________________________________
> From: Kohsuke Kawaguchi <k...@kohsuke.org>
>To: jenkinsci-dev@googlegroups.com
>Sent: Wednesday, November 28, 2012 10:19 PM
>Subject: [RFC] Database plugin
>
>
>Over the Thanksgiving break, I wrote the database plugin [1]. The goal of this
>effort is:
>
>
>- Define a common abstraction for plugins that want external database
> connectivity.
>
> The plugin defines the Database class, which represents a capsule
> around JDBC DataSource. The Database class is Describable, because
> it's meant to be configured by admins for plugins that use them.
>
> The immediate driver for this was Jenkow plugin, which embeds a
> workflow engine that stores stuff in RDBMS. So the admin would tell
> this plugin what database to connect to, via GUI, and this is just a
> matter of having a property whose type is Database [3].
>
> The plugin then uses Database.getDataSource() to retrieve DataSource,
> then use it.
>
>
>- I want to create a global Database instance that's available to
> plugins for use. I think some plugins would find such a storage
> useful, and I think it's better for the admin to configure it once
> and let all interested plugins use it, as opposed to every plugin
> coming up with its own places to store stuff.
>
>
>- I want to also create a per-job file-backed embedded Database
> instance that plugins can use to store job-scoped stuff (like test
> reports and analysis results.)
>
> This appeals to me because the ultimate data store for this is still
> under $JENKINS_HOME/jobs/foo/, just that some data are now binary and
> not in XML.
>
>
>
>I think the first feature is non-controversial, and this is already
>implemented, along with several database driver plugins (H2 for embedded,
>MySQL and Postgres because I can!)
>
>But the 2nd and the 3rd ones open up a lot of questions for which I have no
>answer --- name collisions of tables among different plugins, how schemas kept
>in sync with plugin versions, whether they should be higher level abstractions
>to deal with these. Right now, it's just you and Connection (with which anyone
>can execute any SQL.)
>
>Are these interesting? Would any plugin developers interested in using this?
>Any suggestion for abstraction improvements before I release the first version
>of the plugin?
>
>
>[1] https://wiki.jenkins-ci.org/display/JENKINS/Database+Plugin
>[2] https://github.com/jenkinsci/database-plugin
>[3]
>https://github.com/jenkinsci/database-plugin/blob/master/src/test/java/org/jenkinsci/plugins/database/Sample.java
>-- Kohsuke Kawaguchi http://kohsuke.org/
>
>
>
