Re: [Brahms-dev-l] question about cvs

From: Christian Holm Christensen <cholm@nbi.dk>
Date: Fri Apr 14 2006 - 22:23:47 EDT
Hi Hiro,

On Fri, 2006-04-14 at 21:42 -0400, Hironori Ito wrote:
> Hello,  I agree with you that these things should not be stored in cvs.  
> My suggestion would be the following.
> 
> 1st method:   Do similar to the file catalog.  Store the information to 
> locate the required file (or files) from the database.  If the files are 
> important (and can not be remade easily), 

This is kinda crucial.  If Erik can make a small script that generates
the needed histogram(s) (perhaps in memory or on disk), then there
really should be no need to store them centrally - as log as he
documents what needs to be done. 

> then copy also those files to 
> HPSS for archives.

If you go for this option, I think the files should be stored in a way
that's accessible to all - that is, store the files in an (x)rootd
server.  If BRAHMS is not running an (x)rootd server accessible world
wide, it's quite easy to set up one yourself.  coupled with a file
catalogue, and you have a half GRID solution.

> 2nd method:  Or, you can store histogram (or histograms) itself in 
> database.  To do that just serialize it (or them) and store in MySQL as 
> blob.  

Whoha, that's probably not a good idea.  In fact, if I had to redo the
BRAHMS calibration databases, I'd probably go for a file-catalogue+rootd
solution.  Blobs are _evil_. 

> You can do very easily in RUBY with Marshal class.  (or you can 
> do also easily in Java, but I guess that is what our BRAT database codes 
> also do for arrays of data.)

Exactly.   An array of parameters is serialised as a text string, with
additional information that indicates size and type.  It's really not a
good solution, but it's the best I could come up with at the time.  Live
and learn, eh? 

>   But, I am not sure how fast this process 
> is.  


Very _very_ slow.  Encoding and decoding, database connections, and so
on.  

> And, the response of the database might be too slow with larger 
> histograms for someone's taste???

:-)

There's something to be said for trying to keep high-level data like the
DST's free from external data.  Perhaps you should consider getting  the
data needed directly in the code, or make sure the data is used
earlier. 

Yours,

-- 
 ___  |  Christian Holm Christensen 
  |_| |  -------------------------------------------------------------
    | |  Address: Sankt Hansgade 23, 1. th.  Phone:  (+45) 35 35 96 91
     _|           DK-2200 Copenhagen N       Cell:   (+45) 24 61 85 91
    _|            Denmark                    Office: (+45) 353  25 404
 ____|   Email:   cholm@nbi.dk               Web:    www.nbi.dk/~cholm
 | |

_______________________________________________
Brahms-dev-l mailing list
Brahms-dev-l@lists.bnl.gov
http://lists.bnl.gov/mailman/listinfo/brahms-dev-l
Received on Fri Apr 14 22:24:04 2006

This archive was generated by hypermail 2.1.8 : Fri Apr 14 2006 - 22:24:11 EDT