[Babase] sexskins upload errors_no mdates
Karl O. Pinc
kop at meme.com
Sat May 10 14:02:15 EDT 2008
On 05/08/2008 02:17:39 PM, kfenn wrote:
> I've been trying to upload some sexskin size data through the
> cycles_sexskins view and I am running into a lot of errors, many of
> which I've figured out but I'm also gettting a lot of:
> "No mdate found for this cycle".
>
> I though Babase generate automatic mdates for cycles so I don't
> understand why the mdates aren't there. Would you suspect this to be
> a cycgaps issue? Under what circumstances would Babase NOT create
> automatic mdates?
As we figured out on the phone together the Mdates are not there
because these are the resumption cycles after pregnancy.
I found 2 bugs in the system related to sexskins.
First, as we found during our phone call, the test for whether
the cycle associated with the sexskin has an Mdate was not
properly checking whether the cycle was one of resumption
after pregnancy. (It was testing sexskins.cid = pregs.resume,
which does not work because pregs.resume does not have a
cycles.cid value.) (Fix in db/triggers/sexskins.m4)
Second, I took another look at the automatic assignment of sexskins to
cycles with pregnancies in mind and found that the code was not
testing for pregnancy. It was assigning the sexskin to the cycle of
the CYCPOINTS row on or before the SEXSKINS.Date value, and failing
over to the CYCPOINTS row after SEXSKINS.Date when such a row did not
exist. This means that when there's no Mdate after a pregnancy the
preceeding CYCPOINTS row will be the Zdate, and any sexskins belonging
to the resume cycle but before the Tdate of the resume cycle are
erroneously assigned to the conception cycle not the resume cycle.
(fix in db/include/globalmacros.m4)
I fixed these problems and installed the code. Please test.
Run the tests in babase_test first. I've tested, but no
point in mucking up the real data if there's still a problem
somewhere. Thanks.
This leaves 2 potential problems with the sexskin data in the database.
Please double check my analysis here, at least as far as you can.
(If you like, read the code and check my fix there too.)
1)
Sexskins occurring after a conception but before the Tdate are assigned
the
wrong cycle. (The prior cycle, the conception cycle.)
I leave it to you Tabby to write this query and see what kind of problem
exists. Probably the best way to fix it is to reassign the sexskins.cid
column to the right value. Your changes won't actually mean anything,
the system will re-figure out and make the correction and ignore the
value you supplied, but it's a convenient thing to change to trigger
the automatic reassignment.
If you don't find this data problem, that's suspicious.
It means I will have to review the change I made to the code.
Please let me know.
2)
Sexskins where there's a pregs.resume that's got a cpid equal to some
cid can get away without having an Mdate. This query finds the bad
sexskins:
select sexskins.sxid, sexskins.date, sexskins.size, sexskins.cid
from sexskins, pregs
where pregs.resume = sexskins.cid
and not exists (select 1
from cycpoints as thisc
where thisc.cid = sexskins.cid
and thisc.code = 'M');
The outer query finds those sexskins that _could_ have passed
the buggy validation test, and the inner query finds which of
those have a problem if they don't fall into one of the exceptions
that are allowed to have no Mdate. (I don't bother with the
extra code to test the exceptions.)
Turns out this returns only sexskins where the previous cycle was
a pregnancy, so there's not any problem in the database. No
bad data slipped through.
Please post on babaseannounce when you determine the
extent of the problem/fix the data.
Karl <kop at meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
More information about the Babase
mailing list