On 12-10-03 09:51 AM, Tobias Wunden wrote: > Hi Greg, > > as discussed during the meeting, it may or may not be a good idea to move the > mediapackage xml out of the database. The idea of it being in there is that > the mediapackage is an argument to the 'start workflow' operation, and the > service registry and its job dispatching facility stores the arguments for > service calls in the database so there can be failover. > If we now move the mediapackage out of the db onto the filesystem and replace > the db entry with a file:// or http:// url instead, job dispatching can be > completely broken by cleaning up the working file repository or random places > on disk. > > From my point of view, this suggest investigating whether there is a datatype > that is better suited such as a BLOB or anything similar, since Matterhorn > only uses the field for later reference, not for querying, searching or the > like.
Ok, fair enough. What about using JPA to store the mediapackage as objects in the DB? This would prevent overflow from any column at, perhaps, the cost of a hit on the DB and some serialization to/from the XML itself. G > Tobias > > On 29.09.2012, at 00:02, Greg Logan <[email protected]> wrote: > >> Hi folks, >> >> I have a question for those familiar with the job architecture: Why do >> we store the mediapackage xml in the jobs table? Why not a link to the >> file in the filesystem? I have multiple captures here which overflow >> the payload column during distribution. Everything else works, just >> this particular piece of media appears to have a lot of scenes. I am >> uncomfortable changing the segmentation settings since they obviously >> work fine as is. I'm processing this lecture instead as a >> presenter/source to avoid the scene detection, but this is an extremely >> wasteful workaround. >> >> I'm tempted to propose that we should move that file onto disk where it >> belongs in 1.5, but I'm not familiar enough with the jobs architecture >> to say for sure. Could those who are more familiar with it (Tobias? :)) >> chime in and give me a hint of how much work is going to be involved here? >> >> Thanks, >> >> G >> >> _______________________________________________ >> Matterhorn mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
