> >> > 2) When item, metadata or bitstreams are changed (modified or >> > removed), I wish to update various metadata fields to ensure that >> > they are consistent with the data held in the item. >> >> Consistency constraints form a very interesting class of use-cases. >> Are these changes coming though the admin UI, or elsewhere, or >> anywhere? >> Do you want a consistency check to be performed on any change, or >> only >> certain ones, etc?
>> This would be specific fields. For example, I maintain dc.coverage.* >> metadata that I wish to generate from either a user interface or from >> data in bitstreams. Also be sure that the event handler is "stable", by which I mean that if there is no change in the DSpace Item's content and metadata (or, at least, no change to any features it cares about), it does _not_ make any modifications. As you can guess, it could get into an infinite loop of events if it made some modification (which then, ideally, spawns more events) even when there was effectively no change. Since the event consumer environment doesn't give you a very detailed view of what changed, I imagine your code examines the whole Item to compute its derivatives? So long as it skips making changes when the derivatives don't actually change, it ought to be safe from loops. >> >> we have talked about providing an in-process asynchronous message >> queue >> consumer (we already have a prototype enterprise JMS queue, if you >> would >> want to look at that, but it might be over-kill). Let me know if you >> are >> interested in this alternative.I'm interested. The original prototype on the wiki included this, but since the code that got adopted is significantly different, it would take some work to port it. See the wiki page http://wiki.dspace.org/index.php/EventSystemPrototype Specifically, the section: http://wiki.dspace.org/index.php/ EventSystemPrototype#Optional_Asynchronous_Support_2 ..and also note there aer some pitfalls specific to the ActiveMQ JMS implementation. The original prototype code is available in files that are no longer linked in the wiki: http://wiki.dspace.org/index.php/Image:Event1.5-new-source.zip http://wiki.dspace.org/index.php/Image:Event1.5-diffs-source.txt http://wiki.dspace.org/index.php/Image:Event1.5-diffs-exit.txt > >> As to your current code, I can see how this will work, and it's fine >> in the interim, but I don't think in future releases we will want to >> expose bare DB connections (getDBConnection()), since this breaks >> some encapsulations we are striving for in our DAO and other work.I >> expected this. So I'm still looking for a long term solution. > > John > > John >> > _______________________________________________ DSpace-tech mailing >> list [email protected] >> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> > ----------------------------------------------------------------------- > -- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/ > index.php_______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
