[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