Skip to content
  • Leigh B Stoller's avatar
    Begin the transition away from the ancient Mysql.pm module to the more · 5030b44d
    Leigh B Stoller authored
    current and maintained DBI::mysql module. A couple of things make this
    a little more work then you might think.
    
    Mysql exports a slightly different API then DBI, both at the DB *and*
    the statement level. The former required some restructuring of
    emdbi.pm, partly cause we want external sites to continue using Mysql
    for a while longer. So, emdbi suppports both interfaces, via the
    configure variable TBUSEDBI.
    
    I also took the opportunity to also scrap the existing fork()
    detection code and redo it in an easier to understand manner.
    Actually, I had no idea what the previous code was trying to do, so it
    was easier to just get rid of it, rather then try to make it work for
    the DBI API.
    
    There are also API differences in the "statement" class, but
    fortunately this can be hidden by wrapping the statement class with a
    wrapper that adds the routines we need to avoid making silly changes
    to 1000s of queries. They are all trivial little things since mostly
    its a matter of naming (numrows --> rows).
    
    I also changed the library we use on ops (db/libtbdb.pm.in) to use
    DBI, but in this case I just switched it over. Seemed like overkill to
    worry about supporting both APIs on ops. If it works it works, and so
    far it does. 
    
    Lastly, the following modules still use Mysql directly. They all need
    to be changed, but none of these are on the critical path to swapin
    and swapout, so they can change later.
    
    db/dumperrorlog.proxy.in
    db/showgraph.in
    db/sitevarscheck.in
    bgmon/find-asymmetric
    db/pelab_opspush.proxy.in
    slothd/sdisrunning.in
    utils/export_tables.in
    utils/setbuildinfo.in
    pelab/bgmon/libpelabdb.pm
    pelab/dbmonitor/libtbdb.pm
    5030b44d