Hi Robin, I have indeed used Minho, but it breaks an easy upgrade to 1.5.1, modifies the dspace db schema and low-level source code like Constant.java, etc... which are things I wanted to avoid. My idea when I started this was to achieve similar results, but (a) not touch the dspace DB, (b) not use procedural languages, (c) don't patch source code. Basically make sure that it was essentially isolated from dspace and wouldn't affect upgrade paths at all.
(It's also very buggy, I've talked to a fair few universities here in NZ that have decided to remove it) I do share your concerns about dspace.log. I still can't quite figure out how it rotates them.. it often appears to be writing to two logs simultaneously, and I wouldn't be surprised if some entries get lost occasionally. Mark Wood's "EventUsage" plugin (somewhere on Google Sandbox or in the SVN prototypes I think) is excellent, as an alternative to reading dspace.log. I'm hoping it makes it into the next release. To put it another way, I would say my work is closer to Dspace's built-in stats than the Minho plugin. I have a standalone log parser, and a standalone tool to query my DB. I'm just populating a separate DB of hits, downloads, etc., rather than building the .dat reports. I'm sure it's not perfect, but we've already ruled out Minho for our repositories, and I've looked at a few other in-house solutions and have taken ideas from them but haven't seen anything that really "stays out of the way" as far as separating it from Dspace goes. Cheers, Kim. > -----Original Message----- > From: Robin Taylor [mailto:robin.tay...@ed.ac.uk] > Sent: Tuesday, 3 February 2009 12:11 a.m. > To: Kim Shepherd; dspace-tech@lists.sourceforge.net > Subject: RE: [Dspace-tech] Reading dspace DB from other applications - > tangent ! > > Hi Kim, > > Apologies for sort of hijacking your thread, I have renamed the title > to allow separate replies. It sounds to me like you have taken a > similar approach to the Minho guys in that you take the dspace log as > your starting point for compiling the stats. In fact if you are not > familiar with their package it would be worth your while having a look. > Whilst this is an attractive approach in that you don't have to mess > around with the existing Dspace code, I have some reservations about > its reliability. To date the log message format has been pretty well > maintained, but in an Open Source environment where patches, plugins, > etc could come from various sources I am not confident that will always > be the case. So my question is, are there any current/planned solutions > that integrate the compiling of stats into the heart of the Dspace > code ? Sorry if I am going over old ground here but its just come onto > my radar so I have only just started paying attention. > > Thanks, Robin. > > Robin Taylor > Main Library > University of Edinburgh > Tel. 0131 6515208 > > > > -----Original Message----- > > From: Kim Shepherd [mailto:k...@waikato.ac.nz] > > Sent: 02 February 2009 00:42 > > To: dspace-tech@lists.sourceforge.net > > Subject: [Dspace-tech] Reading dspace DB from other applications > > > > Hi all, > > > > I'm currently developing a standalone stats package to > > analyse dspace logs and generate usage reports based on some > > custom requirements (similar to built-in stats, but with > > per-author views/downloads statistics, allow search for any > > item/handle to display views/downloads, etc.) > > > > Access to a few tables, such as > > handle,metadatavalue,item2bundle,bundle2bitstream,bitstream > > are needed to resolve handles to IDs and generate reports > > based on author names, print metadata values for items, and so on. > > > > At the moment, I'm too paranoid to let my stats app query > > dspace's DB directly, and am just regularly dumping tables > > from dspace and spitting them over to a separate database. > > However, I'm aware that dspace does protect itself from > > running out of resources with a managed connection pool, and > > that I'm only doing read operations. (no UPDATEs or INSERTs, > > they would only ever happen on my separate stats DB). > > > > Can anyone either (a) confirm that my paranoia is justified, > > or (b) point out some safe ways of querying the dspace DB > > from a standalone app? Increase max connections in postgresql > > to $dspacepool + $statspool + a bit of overhead? > > > > At the moment, dumping to a separate DB works fine, but it > > probably doesn't scale very well and just seems like an ugly > > -- albeit 'safe' -- hack. > > > > Any suggestions or pointers are appreciated. > > > > Cheers, > > > > Kim. > > > > -- > > Kim Shepherd > > IRR Technical Specialist > > ITS Systems & Development > > The University of Waikato > > DDI +64 7 838 4025 > > > > > > -------------------------------------------------------------- > > ---------------- > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > DSpace-tech mailing list > > DSpace-tech@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > > > > > > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
