[Ringing-lib-discussion] Database updating & place notation

[Martin B. <mjb...@li...>]

I've made some changes, not yet uploaded, to the script which populates the 
database.  And to my copy of the database itself.

I've changed the way lead heads are handled.  There are two columns, 
methodLeadHeadCode and methodLeadHead.  If the lead head code is non-NULL 
and the stage is at most 12, then the lead head can be NULL because we can 
get it from another table.  Otherwise the lead head is stored.  The only 
bit of this I haven't done is computing the lead head from the code when 
the stage is greater than 12; Perl code to do this would be gratefully 
received.

I've changed the program to put place notation in `maximal' format, i.e. 
with dots between all changes and with external places present.  This is 
part of a little Ringing::PlaceNotation module which I see going into a 
general ringing utility package.  This module will also be needed by the 
Perl library client module which I've almost written.

I've changed the database by adding a methodIsDifferential column.  What 
should methodClass be set to for Differentials (as opposed to Differential 
Hunters)?

I've put in a process for updating existing methods rather than just adding 
them as new ones.  If a method in the input file has the same place 
notation as one already in the database, it's considered to be the same 
method.  The new data overwrites the old.  Otherwise it's considered to be 
a new method.  This could be easily used to keep the database up to date in 
conjunction with diff.


Now for some questions.

At the moment we store place notation as two symmetrical portions if it's 
symmetrical about the lead end.  That's what people expect.  We store it as 
one long thing if it isn't, even if it is symmetrical about somewhere else. 
Storing a symmetrical method as half the place notation and a lead end 
accomplishes two things:  it indicates that the method is symmetrical, and 
it halves the amount of place notation.

Should we extend this to methods symmetrical about somewhere else?  Such a 
method can always be stored as two symmetrical blocks of place notation. 
It would not be hard to write code to look for symmetry.

Note that questions about how we store data should always be considered 
separately from how we pass it out through the XML interface.  I think 
that, even if we turn symmetrical methods back into one long thing when 
giving them to the user, there could be some use in at least storing them 
as two symmetrical parts.

On the other hand, suppose that a user wants to search for all methods, 
symmetrical or not, which are Cambridge above.  If we store symmetrical 
methods differently from asymmetrical methods then we have to do two 
queries rather than one.

Next, searching for a method up to rotation.  This could be useful.  One 
way to accomplish it would be to store, for each method, some unique 
rotation of its place notation such as the least in lexicographic order. 
Should I implement this?  Incidentally I haven't come up with a good 
algorithm for finding the lexicographically least rotation of a sequence, 
so if anybody out there knows one then please let me know.

I've also put some extra code into DBIx::XMLServer so that you can get out 
information from a query like what page it was, the total number of rows if 
the LIMIT weren't there, the actual SQL query string.  Useful if I want my 
stylesheet which generates HTML to be able to say "page 3 of 5" and have 
links to other pages.

Martin

-- 
Martin Bright
Department of Mathematical Sciences, University of Liverpool