[Babase] Fwd: babase update and conf call

Jeanne Altmann altj at Princeton.EDU
Thu Sep 14 07:21:36 EDT 2006


I realize that would be better for me as well,
j 

-----Original Message-----
From: babase-bounces at eeblistserv.princeton.edu
[mailto:babase-bounces at eeblistserv.princeton.edu] On Behalf Of Susan
Alberts
Sent: Wednesday, September 13, 2006 12:57 PM
To: The Baboon Database Project
Subject: RE: [Babase] Fwd: babase update and conf call

No worries, we knew you were in transit. I believe that Karl has a call
with Jun tomorrow morning so perhaps we should do 2:30.

Susan

>Sorry, you have probably been waiting on me, Just got into Princeton 
>and found loads of messages, Either time is ok for me also, jeanne
>
>-----Original Message-----
>From: babase-bounces at eeblistserv.princeton.edu
>[mailto:babase-bounces at eeblistserv.princeton.edu] On Behalf Of 
>Catherine Markham
>Sent: Tuesday, September 12, 2006 6:46 PM
>To: The Baboon Database Project
>Subject: Re: [Babase] Fwd: babase update and conf call
>
>Hi all,
>
>Wow - that's fantastic news about progress with the system!
>
>Unless something comes up with my schedule at the last minute (there 
>are still a few TBA things that I'm on hold for), count me in for the 
>conference call on Thursday.  Either of the times Susan mentioned (10 
>am or between 2:30 and 3:30) should work great.
>
>Thanks,
>Catherine
>
>
>
>Susan Alberts wrote:
>>  Sorry, I don't know why I didn't send that the mailing list! Here is

>> it again.
>>
>>  Susan
>>
>>  Begin forwarded message:
>>
>>>  *From: *Susan Alberts <alberts at duke.edu <mailto:alberts at duke.edu>>
>>>  *Date: *September 12, 2006 5:24:13 PM EDT
>>>  *To: *"Karl O. Pinc" <kop at meme.com <mailto:kop at meme.com>>, Jeanne  
>>> Altmann <altj at Princeton.EDU <mailto:altj at Princeton.EDU>>, KETHERINE

>>> FENN <kfenn at Princeton.EDU <mailto:kfenn at Princeton.EDU>>, Leah Gerber

>>> <lgerber at duke.edu <mailto:lgerber at duke.edu>>, Catherine_Markham  
>>> Markham <amarkham at princeton.edu <mailto:amarkham at princeton.edu>>
>>>  *Subject: **babase update and conf call*
>>>
>>>  Dear all,
>>>
>>>  Karl is about to reach a solid end point and we are excited about  
>>> this. There are some loose ends that will need to be tied up, and we

>>> think that a babase conference call for Thursday would be a good  
>>> thing. We would really love Catherine to be involved if at all  
>>> possible becuase of her relatively long history with babase (and as 
>>> a
>
>>>  future user), but I realize her schedule is now quite different.
>>>
>>>  Jeanne and I have a different conf call at 11. We could do our 
>>> babase
>
>>>  conf call before that, at 10 am, or we could do it bewtween 2:30 
>>> and  3:30. That is about all the time that I have free that day. If 
>>> that  can't work out then let me know and we will discuss another 
>>> time  after Karl is back in Chi, but it seems like it would be good 
>>> to do  it before he leaves here (but not absolutely necessary).
>>>
>>>  Here is the update and agenda for our call:
>>>
>>>  Here are the things that still need to be done before Karl leaves.
>>> 
>>>
>>>     1. Cycgaps validation and assigning cycles.series AND automatic
>>>        cycgaps updateing. This is in progress now.
>>>     2. Reconversion using the new automatic updates.
>>>     3. Update Ranks documentation (is this the last table for which
>the
>>>        documentation reflects the old foxpro system?)
>>>
>>> 
>>>  At that point, the conversion is done, except for then debugging to

>>> deal with conversion errors that are programming errors (if any).
>>> 
>>>  After this final conversion, there are some things that we will 
>>> need  to do and decisions we need to make that affect how we use the

>>> database (I am NOT including in this list the things that we all 
>>> know
>
>>>  are outstanding, such a developing the data entry procedures, 
>>> adding  new tables, creating new ranker, and fixing the front end).
>>> 
>>>
>>>     1. *Non-trigger error checks.* There are a set of error checks
>that
>>>        we can run to check the integrity and accuracy of the
database.
>>>        The errors that this would find are not errors that could or
>>>        should be coded as automatic triggers, hence we will describe
>>>        these as non-trigger error checks. They are things like
>checking
>>>        that every animal present in the group has a rank assigned
(as
>>>        opposed to checking that no one is assigned a rank unless
they
>>>        are in the group - this latter one is a trigger, the former
>  >>       cannot be because before ranks are assigned, no one has a
>>>        rank).  Karl notes that we have always had these non-trigger
>>>        error checks available to run in foxpro, but that no one has
>>>        every really run them or used them to identify and correct
>>>        errors. Hence, they are effectively optional error checks.
The
>>>        code has been written for these error checks, but not
debugged
>>>        and hence not run before. Our options are:
>>>           1. Take the error checks that Karl has written and debug
and
>>>              run them ourselves, one by one as needed. They are sql
>>>              queries, so this is highly feasible but laborious.
>>>           2. Have Karl debug and concatenate them into a single
>program
>>>              that would be run whenever we wanted it to be, probably
>>>              automatically on a regular basis.
>>>           3. Outsource this project to someone else - i.e., hire
>>>              someone to concatenate and debug these programs into a
>>>              single program that would be run automatically.
>>>     2. *Testing and pushing the system.* Karl's concern as a
>>>        professional programmer is that we find the worst bugs early
on
>>>        and fix them. He points out that of course there will be
bugs.
>>>        To find them, we need to push the system - do a lot of
>>>        manipulation of the tables using babase_test. Update rows,
>>>        delete rows, make illegal and legal changes and see how the
>>>        system performs. Ideally this should be done for all tables,
>all
>>>        columns. The sexual cycles tables should have special
attention
>>>        here because there are so many "analyzed" tables. This kind
of
>>>        testing will also reveal performance issues that might come
up
>>>        that we haven't anticipated or found yet.  One approach would
>be
>>>        to just devote a certain amount of time in Leah's and Tabby's
>>>        week, some week, to doing this. Another option would be
>>>        contracting Karl or someone else to do this. It might be a
>>>        couple of days work, hard for me to say.
>>>     3. *Dealing with warnings and unwanted error messages.* Every
>>>        night, the program will run the triggers, and these automatic
>>>        checks will produce a list of error messages and warnings
>>>        related to data "errors" in the database. Specifically,
anytime
>>>        a rule is violated (rules outlined in the documentation) a
>>>        message will appear. Some of these we will want to ignore
>>>        forever or for the time being, and we will not want to be
>>>        revisited with them every day. So, Karl proposes a program
that
>>>        will defer or eliminate unwanted error messages and warnings.
>>>        This is optional, but would be a great convenience. It is not
>>>        really something that I think is feasible for us to do
without
>>>        professional help, unless Leah or Tabby have insight into
this.
>>>        What to do?
>>>     4. *Checking cycle ids?* Karl points out that in creating the
new
>>>        cycle files in the new babase system, cycles have different
>cids
>>>        in many cases than they did in the old babase system. He
wants
>>>        to know whether we want a program that maps old onto new, so
>>>        that we can find particular cycles that we analyzed in
foxpro.
>>>
>>>
>>>  -----------------------------------------------
>>>  Susan Alberts, Dept. Biology, Duke University, Durham NC 27708. 
>>> Phone
>
>>>  919-660-7272, Fax 919-660-7293. alberts at duke.edu  
>>> <mailto:alberts at duke.edu>
>>>
>>>
>>>
>>
>>  -----------------------------------------------
>>  Susan Alberts, Dept. Biology, Duke University, Durham NC 27708. 
>> Phone  919-660-7272, Fax 919-660-7293. alberts at duke.edu  
>> <mailto:alberts at duke.edu>
>>
>>
>>
>>
>>  
>> ---------------------------------------------------------------------
>> -
>>  --
>>
>>  _______________________________________________
>>  Babase mailing list
>>  Babase at www.eco.princeton.edu
>>  http://www.eco.princeton.edu/mailman/listinfo/babase
>_______________________________________________
>Babase mailing list
>Babase at www.eco.princeton.edu
>http://www.eco.princeton.edu/mailman/listinfo/babase
>
>_______________________________________________
>Babase mailing list
>Babase at www.eco.princeton.edu
>http://www.eco.princeton.edu/mailman/listinfo/babase


--
------------------------------------------------------------------------
--------------------------------------------------------------
Susan Alberts, Department of Biology, Duke University, Box 90338, Durham
NC 27708
919-660-7272 (phone), 919-660-7293 (FAX)
_______________________________________________
Babase mailing list
Babase at www.eco.princeton.edu
http://www.eco.princeton.edu/mailman/listinfo/babase



More information about the Babase mailing list