[freeside-devel] 1.4.0pre7

ivan ivan at 420.am
Wed Dec 26 21:34:57 PST 2001


On Wed, Dec 26, 2001 at 02:38:54PM -0600, Dave Burgess wrote:
> 
> 
> On the MySQL split -
> 
> What mechanism do you see putting in place for the differences in the database
> structures?  A Conf.pm change, or something a little more heuristic (if
> "SELECT" A fails, try "SELECT" B)?

It's not nearly that bad.  Schema differences are handled by
DBIx::DBSchema (you can ask for schema information at runtime), and
runtime datatype weirdness is handled in FS::Record.

For selecting different SELECT syntax, you can use the `driver_name'
subroutine provided by FS::UID.  For example, in FS/bin/freeside-queued,
there's a code fragment like:

    driver_name =~ /^mysql$/i
      ? 'ORDER BY jobnum LIMIT 1 FOR UPDATE'
      : 'ORDER BY jobnum FOR UPDATE LIMIT 1'

> The reason I ask is because the following SELECT "select max(version()) from
> agent" will give you the MySQL Version number.  We know that the sub-select
> queries don't work in anything older than 4.1, and work in the current
> PostgreSQL release, so is there a way to use that information to 'prepare' the
> select accordingly.  Basically, the old select (as slow as it was) worked
> adequately under the old MySQL version, so we should (I'd think) be able to
> programatically decide which select we were going to use.  If you just leave
> the old select structure in place and add 'improved' selects for newer DBMS
> versions, we'd be in good shape.

Agreed.  I've only done things that trigger based on database
(mysql or Pg), and not on version, but I'd have no objections to getting
that fine-grained if necessary.

The problem with currently supporting MySQL is that the new queries are
needed to support any sort of efficient `max search records per page'
configuration option.  There is no working "old select structure" that
could work with the `maxsearchrecordsperpage' option.

-- 
_ivan



More information about the freeside-devel mailing list