On Wed, Feb 29, 2012 at 12:28 PM, Peter Cock <p.j.a.c...@googlemail.com> wrote:
> On Wed, Feb 29, 2012 at 5:14 PM, Greg Von Kuster <g...@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

___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Reply via email to