MonkPaul has asked for the wisdom of the Perl Monks concerning the following question:

Hello All,

Im trying to think of a way to create files on a server that can be used for future use.

My problem begins with the user uploading two files of BLAST output, (bioinformatics tool), a new blast output and an old blast reference file that contains the accession numbers of the hits to a sequence. The new file accessions are compared to the old and any new additions are shown to the user on the screen, whilst their accession numbers are inserted into the old file, thus creating a new reference file for future comparisons.

What i was thinking was that these updated files could be kept on the server system so they dont have to upload them each time. (??? im not sure at this point if this is the right thing to do)

Could it be that i am best to just update the old reference file and save it where the new blast output was loaded from. In this case how can i specify the dir to save the new file.

Cheers,
MonkPaul

Replies are listed 'Best First'.
Re: Creating files on a server
by muzakfetch (Scribe) on May 28, 2005 at 16:05 UTC
    You could also use DBD::SQLite in this scenario, just to store basic information. It's fast, lightweight and easy to get rolling with.

    Also, I'm thinking that you want to use Text::Diff maybe? This way you can show the users the differences between the old and new files fairly easily.

    This may also be a good use for Subversion or CVS if you're consistently dealing with files and differences but want to maintain some kind of versioning scheme.

    Hopefully these ideas help a little? If you possibly get into a little more detail of the whys and the overall user process everyone could make a better determination of what you want to accomplish.

    muzakfetch
Re: Creating files on a server
by tlm (Prior) on May 28, 2005 at 14:29 UTC

    I'm not sure I understand your description of the problem entirely, but if I do, I would set up a (e.g.) MySQL DB on the server to hold each user's info, which can include collections of accession numbers. Users would need to set up accounts, etc.

    the lowliest monk

      Sure that sounds like another good idea.
      I had contemplated that but im in a bit of a pickle with what to do next.

      I have no real functional description at this point so im not sure where to go next.

      The DB idea i think would be the way forward, although i then have to think of table structure, relationships and data validation.

      How easy is it to allow users to set up accounts in a MySQL DB?

      MonlPaul.