Am 29.11.2012 um 05:52 schrieb Bruno P. Kinoshita <[email protected]>:
> 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].
>
+1
Thanks for adding that! I always wanted to add that to my analysis plug-ins but
did not yet find some spare time for that change…
>> 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.
>
I think that is not a big problem as we have the same problem with the file
layer. Currently my plug-in stores its results in a file findbugs.xml which can
be overwritten by other plug-ins. I think the same would be true for a table
"findbugs".
And having a prefix (or schema) as noted by Bruno will make it even more
unlikely.
>> 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?
I think each plugin is responsible to add code (or scripts) to migrate a schema
from release to release (as this is currently done in the readResolve methods).
That part is required for any application that works with databases…
It would be nice if we would provide an appropriate framework that simplifies
that task for plug-in developers.
>
>> 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?
>
I'm not really sure: should we also provide a way to handle the actual
persistence? I.e., are we writing a DAO with plain JDBC and SQL? Or are we
using a OR-Mapper like Hibernate? Or is that up to the plug-in developers?
What would be also interesting: are there use cases that would work better if
we would use a NoSQL database like Mongo DB rather than a relational database?
In that case we would not need JDBC at all…
Anyway, thanks for adding that to Jenkins!
Ulli
> 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 <[email protected]>
>> To: [email protected]
>> 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/
>>
>>
>>
