On Wed, Feb 29, 2012 at 12:28 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Wed, Feb 29, 2012 at 5:14 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Hi Carlos,
You can certainly add support for a sqlite database datatype to your local galaxy instance. As you say, it may be no more complex / fragile than h5 or other binary datatypes - I've not gone far enough down the analysis path to provide good reasons why it may or may not be reasonable, so perhaps I spoke too soon. If you have questions about how to add support for new datatypes, see our wiki at http://wiki.g2.bx.psu.edu/Admin/Datatypes.
Thanks!
Greg Von Kuster
My impression is that as long as you treat it as a write once-data-read- many file using an SQLite3 database in Galaxy could work. By that I mean any tool can create and modify SQLite3 files as some of its output files, and any tool can also have any number of SQLite3 files as inputs - but must treat them as read only.
The trouble will start if you actually use a pre-existing SQLite3 file like a database and make changes to it. That will break Galaxy's assumptions about how to reproduce the file for workflows etc.
Perhaps Galaxy should actively preempt the possibility of tools editing old data files by making all the history data files read only right after the tool creating them has finished? This could catch some existing 'naughty' tools editing things they are not meant to.
Peter
Hi Peter, This is a good point. I agree making sure the sqlite file is treated as read only would be a good idea. Thanks, Carlos