Re: Jenkins Database Envy - is it just me?
https://github.com/mbarbine/JenkinsDB On Friday, October 12, 2012 11:39:41 AM UTC-4, Mandeville, Rob wrote: > > I’ve been using Jenkins for a couple of years (starting back before the > Hudson/Jenkins fork) and it has saved my career on several occasions. > However, I’m getting some database envy. I want to be able to read from > and write to the database of builds and build results without HTTPing > through the server. I’d also like to not have everything in core all the > time (the lazy-loading feature in 1.485 was, IMHO, a case of DB envy). > What I’d love to see is to have the file-based persistence layer connecting > to a JDBC data source, probably shipping with embedded HSQLDB or something > by default. > > > > But my question is: is it just me? > > > > I’m using Jenkins in a fairly heavy-duty way (and investigating if we > should upgrade to CloudBees Enterprise Edition), and effectively have a > separate database, build parser, and build results web site so that we can > see results going back several years and query it in multiple ways. I > don’t think that I’m your typical Jenkins user. In fact, I can see reasons > not to use a DB persistence layer: the files that the Jenkins server keeps > for its configuration and logs are pretty human-readable, and having a DB > persistence layer would require a DB connection to look at. I also realize > that, even if we did want to go to a DB layer, this would be an expensive > process that would take resources away from adding more features to Jenkins. > > > > So how many people would like to see a DB layer, how many wouldn’t, and > how many don’t care how it keeps its data under the hood? > > > > --Rob Mandeville > > Litle & Co. > > > The information in this message is for the intended recipient(s) only > and may be the proprietary and/or confidential property of Litle & Co., > LLC, and thus protected from disclosure. If you are not the intended > recipient(s), or an employee or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any use, > dissemination, distribution or copying of this communication is prohibited. > If you have received this communication in error, please notify Litle & Co. > immediately by replying to this message and then promptly deleting it and > your reply permanently from your computer. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Jenkins Database Envy - is it just me?
My thoughts on the discussion I have also tried to work with Jenkins which have the same requirement: "I want to be able to read from and write to the database of builds and build results without HTTPing through the server. I’d also like to not have everything in core all the time" Though, do we need a database? Maybe we just need to improve the Jenkins cmd-line and some of the features in which Jenkins manages its build-data. I personally like designing/developing systems using VIEW-Objects, Business-Objects and Data-Access-Objects. The Data-Access-Objects can access either a dbase, filesystem, or anything you desire, without affecting the core. ... Marek On Fri, Oct 12, 2012 at 11:39 AM, Mandeville, Rob wrote: > I’ve been using Jenkins for a couple of years (starting back before the > Hudson/Jenkins fork) and it has saved my career on several occasions. > However, I’m getting some database envy. I want to be able to read from > and write to the database of builds and build results without HTTPing > through the server. I’d also like to not have everything in core all the > time (the lazy-loading feature in 1.485 was, IMHO, a case of DB envy). > What I’d love to see is to have the file-based persistence layer connecting > to a JDBC data source, probably shipping with embedded HSQLDB or something > by default. > > ** ** > > But my question is: is it just me? > > ** ** > > I’m using Jenkins in a fairly heavy-duty way (and investigating if we > should upgrade to CloudBees Enterprise Edition), and effectively have a > separate database, build parser, and build results web site so that we can > see results going back several years and query it in multiple ways. I > don’t think that I’m your typical Jenkins user. In fact, I can see reasons > not to use a DB persistence layer: the files that the Jenkins server keeps > for its configuration and logs are pretty human-readable, and having a DB > persistence layer would require a DB connection to look at. I also realize > that, even if we did want to go to a DB layer, this would be an expensive > process that would take resources away from adding more features to Jenkins. > > > ** ** > > So how many people would like to see a DB layer, how many wouldn’t, and > how many don’t care how it keeps its data under the hood? > > ** ** > > --Rob Mandeville > > Litle & Co. > > ** ** > The information in this message is for the intended recipient(s) only > and may be the proprietary and/or confidential property of Litle & Co., > LLC, and thus protected from disclosure. If you are not the intended > recipient(s), or an employee or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any use, > dissemination, distribution or copying of this communication is prohibited. > If you have received this communication in error, please notify Litle & Co. > immediately by replying to this message and then promptly deleting it and > your reply permanently from your computer. >
Re: Jenkins Database Envy - is it just me?
On Fri, Oct 12, 2012 at 10:39 AM, Mandeville, Rob wrote: > I’ve been using Jenkins for a couple of years (starting back before the > Hudson/Jenkins fork) and it has saved my career on several occasions. > However, I’m getting some database envy. I want to be able to read from and > write to the database of builds and build results without HTTPing through > the server. I’d also like to not have everything in core all the time (the > lazy-loading feature in 1.485 was, IMHO, a case of DB envy). What I’d love > to see is to have the file-based persistence layer connecting to a JDBC data > source, probably shipping with embedded HSQLDB or something by default. > > > > But my question is: is it just me? I've always thought that filesystems were a nice place to keep files... -- Les Mikesell lesmikes...@gmail.com
Jenkins Database Envy - is it just me?
I've been using Jenkins for a couple of years (starting back before the Hudson/Jenkins fork) and it has saved my career on several occasions. However, I'm getting some database envy. I want to be able to read from and write to the database of builds and build results without HTTPing through the server. I'd also like to not have everything in core all the time (the lazy-loading feature in 1.485 was, IMHO, a case of DB envy). What I'd love to see is to have the file-based persistence layer connecting to a JDBC data source, probably shipping with embedded HSQLDB or something by default. But my question is: is it just me? I'm using Jenkins in a fairly heavy-duty way (and investigating if we should upgrade to CloudBees Enterprise Edition), and effectively have a separate database, build parser, and build results web site so that we can see results going back several years and query it in multiple ways. I don't think that I'm your typical Jenkins user. In fact, I can see reasons not to use a DB persistence layer: the files that the Jenkins server keeps for its configuration and logs are pretty human-readable, and having a DB persistence layer would require a DB connection to look at. I also realize that, even if we did want to go to a DB layer, this would be an expensive process that would take resources away from adding more features to Jenkins. So how many people would like to see a DB layer, how many wouldn't, and how many don't care how it keeps its data under the hood? --Rob Mandeville Litle & Co. The information in this message is for the intended recipient(s) only and may be the proprietary and/or confidential property of Litle & Co., LLC, and thus protected from disclosure. If you are not the intended recipient(s), or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is prohibited. If you have received this communication in error, please notify Litle & Co. immediately by replying to this message and then promptly deleting it and your reply permanently from your computer.
