Why should we take the error prone path of decomposing the media package if it is just an argument to workflow? Wouldn't it be better to use a CBLOB type -- e.g. LONGTEXT in mysql is capable of storing up to 4GB -- that can take an arbitrary amount of data and serialize the media package as plain text like we're doing right now? No code changes are necessary just a switch to a different data type in the db.
Christoph Am 03.10.2012 um 18:19 schrieb Christopher Brooks <[email protected]>: > Greg, > >> 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. > > Just to clarify, you are suggesting that the fields be decomposed by > JPA and stored as individual columns in the table, and not that the > Java object is serialized to binary and stored as a BLOB, right? > > Chris > > -- > Christopher Brooks, BSc, MSc > ARIES Laboratory, University of Saskatchewan > > Web: http://www.cs.usask.ca/~cab938 > Phone: 1.306.966.1442 > Mail: Advanced Research in Intelligent Educational Systems Laboratory > Department of Computer Science > University of Saskatchewan > 176 Thorvaldson Building > 110 Science Place > Saskatoon, SK > S7N 5C9 > _______________________________________________ > 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] _______________________________________________
