[Babase] VIV demog notes or RANK error
Karl O. Pinc
kop at meme.com
Wed Sep 10 15:25:03 EDT 2008
On 09/10/2008 09:14:42 AM, kfenn wrote:
> I was trying to upload some demog notes for Viola's group into
> demog_census. VIV is censused (present) on two days in Viola's group
> (check babase_test if you want) and I needed to add a note that she
> was hanging around with a subgroup. I get the following message
> regarding both demog notes I am trying to upload:
>
> ERROR: Cenid 1978378: VIV: Individual ranked in RANKS but no longer
> in supergroup on Rnkdate
>
> Here are the formatted notes:
> VIV 2008-06-21 1.22 1.22 VIV, along with VOG, RWA,
> VOH, and LOG rejoined the group at 0900 on the plain between grove
> 118 and TZC. The group slept in TZC. We don't know where they slept.
>
> VIV 2008-01-24 1.22 1.22 VIV was part of a subgroup of 9
> individuals found alone and must have spent the night away from the
> rest of the group. They did not rejoin the group during the field
> session.
> I don't see any conflict in the dates, grp or reference numbers. I
> also don't see why the system in complaining about the RANKS when her
> last ranking was in Dec 2007 for Viola's group and there are no
> conflicting 2008 ranks yet input for her.
>
> Could this be a bug?
Yes. And there may be more to be done.
At minimum the error message could use more work
(But see below regarding assumptions.) Can you come up
with something better?
Here's the problem: When you change census rows the system wants
to make sure you're not changing things so as to violate
the rule that you have to be in a group, or subgroup of the group,
to be ranked in the group. It turns out that even though
you're not really changing the census row in the above cases
when you insert into demog_census, the system isn't sure and
runs the update checks anyway. So, for whatever reason,
the checks get done in this case.
When the system checks the rankings it's not really sure what
dates to check. Interpolation is complicated and could move
an individual between groups over all sorts of time periods.
Rather than worry about what might get changed, the system
just checks _every_ ranking for that individual. It
ran a query that looks like this:
select *
from ranks
where ranks.sname = 'VIV'
and not exists (
select 1
from members, groups
where members.sname = 'VIV'
and members.date >= ranks.rnkdate
and members.date < ranks.rnkdate
+ CAST ('1 month' as interval)
and members.grp = groups.gid
and supergroup(groups.gid, members.date)
= ranks.grp);
If it finds anything, it knows that the ranks are wrong.
At some point the individual is ranked in a group
in which they're not a member or a member of a subgroup.
In this case the query returns:
rnkid | sname | rnkdate | grp | rnktype | rank
-------+-------+------------+------+---------+------
14339 | VIV | 1991-01-01 | 1.20 | ADF | 8
14347 | VIV | 1991-02-01 | 1.20 | ADF | 8
14355 | VIV | 1991-03-01 | 1.20 | ADF | 8
(3 rows)
But before 1991-04-01 1.20 was a sub-group of 1.0
and VIV should be able to be ranked in 1.20. So,
the query really should compare the supergroup
of the MEMBERS row with the supergroup of the
RANKS row, not just the against RANKS.Grp, thusly:
select *
from ranks
where ranks.sname = 'VIV'
and not exists (
select 1
from members, groups
where members.sname = 'VIV'
and members.date >= ranks.rnkdate
and members.date < ranks.rnkdate
+ CAST ('1 month' as interval)
and members.grp = groups.gid
and supergroup(groups.gid, members.date)
= supergroup(ranks.grp, members.date));
I've now fixed this. The note in the change log is:
Individuals can be ranked in any subgroup of the supergroup
so long as they are present in any subgroup of the supergroup
(or the supergroup itself).
This should correspond with what the ranks documentation
says:
Ranks are assigned within groups, so all individuals must be in the
group ranked at some point during the month. Specifically, MEMBERS
must record that the ranked individual is a member of some sub-group
[92]of the ranked group's Supergroup, as determined by the supergroup
() function given MEMBERS.Grp and MEMBERS.Date, during the ranked
month.
Note:
It's not a bad assumption that the operation that
found the problem with ranks is what caused the problem.
However, this is not always the case. I'm not sure
exactly what checks get made when, and when not, but
I'm pretty sure that checks don't always get done
on _every_ database change. I don't think the
system is re-checking all the rankings when you change
the groups table and set what's a supergroup of what
and when the groups came into existence. (Although
it does check the census dates.) What checks got
implemented depended upon the likelihood of any
particular change causing a problem, how hard
it was to implement the check, how likely it is
that a change would be made, etc. There may be
messages that come up in "the big program that
runs lots of queries and looks for errors
and warnings" that isn't being run on a regular
basis to catch conditions not caught a time
of update.
So, there's 2 questions here:
What to do about the error message, if anything.
Has this bug affected rankings, group membership,
or the like? Were changes made that shouldn't
have been made during the conversion or on
other occasions in the past when the error
message showed up and shouldn't have?
Karl <kop at meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
P.S. Next time it would help to be more clear
that you were getting the message from the
babase_test database. I spend a bit of
time poking about the babase database before
figuring out that you'd been doing things
in babase_test.
P.P.S. Babase_test has been vacuumed.
More information about the Babase
mailing list