[Babase] AMO biograph change

Niki Learn nlearn at princeton.edu
Fri Mar 26 12:30:49 EDT 2010


The problem is not creating rows for snames/pids that don't exist but
combining two baboons into one (simply changing a baboon's name would be
more straightforward though I don't know why we would do that anyway).
Basically through genetic analyses we more or less confirmed that AMO is a
Lodge male that we had last seen while he was an infant and so wouldn't have
recognized when he entered the study groups years later.  Changing what
little data there is on BIL to AMO will require many steps but I think the
only part that may generate errors we can't get around through sequencing is
getting rid of BIL and giving AMO his pid (of course AMO is currently listed
as matgrp 9 with no pid).  I can't see babase either letting us remove the
pid from BIL to add it to AMO or adding it to AMO without removing it from
BIL while putting the pid into AMO's biograph record, nor having either two
or no AMO's in biograph while changing BIL's biograph record to AMO.  But
maybe this defer thing would let us remove the pid from BIL and add it to
AMO in two consecutive update statements?  (Not really sure from the webpage
- it was too programmerspeak for me...).

-----Original Message-----
From: babase-bounces at eeblistserv.Princeton.EDU
[mailto:babase-bounces at eeblistserv.Princeton.EDU] On Behalf Of Karl O. Pinc
Sent: Friday, March 26, 2010 12:14 PM
To: The Baboon Database Project
Subject: Re: [Babase] follow up on yesterday's conference call

On 03/26/2010 10:53:37 AM, Niki Learn wrote:


> On BIL to AMO, I think getting him linked to the correct pid should 
> be
> the
> only sticky part.  It might even require removal of certain checks
> temporarily while we delete the pid from BIL and add it to AMO.  I'm
> thinking it probably can't be done with them all in place.

That's always a possibility.  Removing and re-adding many, but not
all, checks is relatively straightforward; although spooky
because the updates that happen without rules in place
are, surprise, not checked.

The checks that are difficult to remove/replace are those
that require an ID be present in another table, e.g. creating
a row for an Sname that's not on BIOGRAPH, a Pid not on
PREGS, etc.  These are known as foreign key constraints.
I suspect that these may be the rules that
cause the most problem.  However there is a database
feature that may make life easier.  You may find that
working within a transaction and deferring the foreign
key constraint checking until you've done all the updating
is the route to solving your problem.  See:
http://www.postgresql.org/docs/8.1/static/sql-set-constraints.html

It's hard to say what's easiest/best.  I'd prefer that the
checks remain in place but there's no point in struggling.
I'll leave it to Niki and Lacey to decide at what point
to call me in and see about temporarily turning rules off.

Karl <kop at meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein


_______________________________________________
Babase mailing list
Babase at www.eco.princeton.edu
http://www.eco.princeton.edu/mailman/listinfo/babase



More information about the Babase mailing list