Source: https://dev.lsstcorp.org/trac/wiki/AstronomicalTablesUsingPython
Timestamp: 2019-04-18 21:10:21+00:00

Document:
I first installed ATpy v. 0.9.0, ran some tests, and uncovered a bug associated with handling a MySQL table with an 8-byte integer data type (see Example 6 below). I e-mailed the ATpy authors and they fixed the bug (along with others), and delivered ATpy v. 0.9.1. I also suggested that it would be more natural to specify database tables by name rather than by index, and they responded by deprecating the "tid" input argument and replacing it with the "table" argument in ATpy v. 0.9.1.
I wrote a unit test for ATpy v. 0.9.1, and it revealed limited-data-precision problems with IPAC, VO, and MySQL tables. These were largely fixed in the latest source code (v. 0.9.2) checked out from their SVN repository. See unit-test results below. MySQL tables have only 15 digits of precision for double-precision data. Thomas Robitaille ran my unit test against a PostgreSQL database and found similar data-precision problems, which he is now investigating.
My plan now is to expand the unit test to cover a broader range of data possibilities, including NaNs?, Infs, etc.
Since EXTNAME = 'IPAC_PTF_MOPS' is defined in the header of the binary FITS table, database table IPAC_PTF_MOPS is created. The CFITSIO library treats EXTNAME as a character string and does not restrict its value from having spaces; however, ATpy will choke if the string does not contain a MySQL-compliant table name.
This created a SQLite database called "russ.db".
The first column of the 12-column MySQL database table is an 8-byte integer data type. This test failed because of the bigint with ATpy v. 0.9.0, but passed with ATpy v. 0.9.1.
I wrote a unit test that covers only IPAC, VO, FITS binary, and MySQL tables. The test consists of a manually constructed 10-row, two-column table, where the data type of the first column is int64 and the second column is float64. There was no issue for the FITS-binary-table case, where the table data were compared with another instantiation of the table data after writing it out to a FITS binary table and then reading it back in. In order to make the test run successfully for the cases involving IPAC, VO, and MySQL tables, I had to use the "assertAlmostEqual" unittest function for the second column of table data. For the MySQL table, the agreement was within 13 decimal places, whereas the IPAC table had agreement to within 8 decimal places, and the VO table had agreement only to within 4 decimal places. I e-mailed the ATpy authors with this information.
# Created: 12 October 2009, Russ Laher (laher@ipac.caltech.edu).
# Unit test for ATpy.  Covers only IPAC, VO, FITS binary, and MySQL tables.
"""A unit test for ATpy."""
# Unit test for ATpy.  Covers only IPAC, VO, FITS binary, SQLite and MySQL tables.
# set up to check for 15 significant digits (it fails for 16, but passes for 15).

References: v. 
 v. 
 v. 
 v. 
 v. 
 v.