This is great! I watched your keynote for JUC SF the other day and got inspired by this idea, so I've started some side investigations around it. The metadata-plugin would really benefit from some kind of database to be able to perform well. Today I am a bit skeptical on how it would perform on larger Jenkins installations like ours (we aren't running it in production yet). But the way we designed it would make it hard to fit into the mold of a RDBMS.
I have been ogling OrientDB [1] for a private hacking-at-home project, and it has the potential of working well for a per-job database as well. I have so far only looked at it on paper, not played around with it for reals yet. * It is pure Java so it can be embedded with Jenkins * Schema less, so changes to classes should work similar to what is already there with today's xml serialization. * It is Document/Graph based * Has a SQL like syntax but without the joins * Easy to use OR mapping layer The only big drawback I've seen so far is that it is using the class' simple name for the table names. So we still have the issue of naming collisions between plugins. But it is Apache 2 Licensed and the OR mapping layer on top of the document layer seems "simple" enough to make some changes to. [1] http://code.google.com/p/orient/ > -----Original Message----- > From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci- > d...@googlegroups.com] On Behalf Of Kohsuke Kawaguchi > Sent: den 29 november 2012 01:19 > To: jenkinsci-dev@googlegroups.com > 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/
