To Do List

This page records desired enhancements to Babase, and possibly includes priorities. We can also use it to list front-ends under consideration and their pros and cons.

Custom Programs

High priority

• Warning system. Current system only reports errors, not warnings. (Warnings can be produced manually, probably.)
• Revision history for babase with ability to undo changes
• Have wwwdiff show line counts when different.
• In wwwdiff have the "by word, not tabular" mode show individual spaces. Currently when there's a difference in the number of spaces in the 2 files you can't tell by looking at the output. (Whitespace needs to be changed to the non-breaking-space html entity.)

Database

Medium priority

Have REPSTATS and CYCSTATS automatically updated.

Low priority

Psionload error message enhancement

The error messages which are produced by Psionload are a bit raw, and we have some suggestions on a couple of them. I'm sure we'll come up with more as we have only seen a few of the error messages thus far.

{{{ "Error: Pntid *****, Nghid *****, Neighbor after statdate blah blah (dead neighbor)"}}}

• ---Pntid and Nghid are irrelevant as the file doesn't actually go into

the system, and can't be searched, it can thus be removed.

Also in the Psionload program, it would be helpful if at the beginning of each error message, the name of the focal animal could be displayed. This makes searching for the error to fix it much easier.

Comment: This is all the same problem. The database does not have the focal individual at-hand when the neighbor is inserted. It just has the neighbor row. I can have the DB query itself to find the focal individual to enhance the error messages. Easy, but involves adding extra code each time an error message crops up.

phpPgAdmin

Needs Work

High priority

• Make changes requested by the PPA team to get our custom changes (the "Done But" below) into PPA.

Medium priority

• The ability to insert/update/delete the database through views in the same way it can be updated through tables. There are two categories of functionality here, individual row maintanence and bulk uploads.

  • Bulk uploads is useful for the regular addition of data. It can be worked around by using the custom [https://papio.biology.duke.edu/programs/upload/ Upload] program (or by use of the Unix interface, which does allow bulk uploads to views.)

  • Individual row maintance is useful for manual corrections. It can be worked around by using sql to update the database rather than a [wiki:Graphical_user_interface GUI].

Low priority

• A 'find' feature for the editing and updating of rows.
• Don't show stuff we don't need to see:
  • Estimated row count column
  • The column with the "Empty" button
• Have the column headings in the SQL output "stick" on the screen.
• Making the "Show Statements" option in SQL window checked by default, with the option to uncheck the box.

Done But

What's listed here has been done but is waiting for inclusion in the offical phpPgAdmin code.

• Rapid display of large amounts of information.
  • Text output of query results added
• The ability to download data directly from a query without having to load the data into a table first.
• SQL command history.
• COPY TO support in user-supplied SQL.

Unreleased

What's listed here has been included in the official phpPgAdmin code, but has not yet been released to the public.

Other TODO

Someday in the far future.... Make up a block diagram showing the different software pieces and how they talk with each other.