The preloading is handy and all but

1. It assumes you want mysql
2. There is no nice way to override/remove that mysql definition.

It'd be nice to be able to define such properties in, say, pod.fan or in a sys.props in ${FAN_REPO}. Well, I say nice. Without being able to do this flexibly, it reduces the usability of having these repos in the first place. If a sys.props (or maybe repo.props?) is the preferred path, i can provide a patch to Sys.java to read there as well after the default sys.props is loaded. What do you think? I'm leaning toward repos.props as doing it in pod.fan seems a bit more complicated.

Probably not documented well enough, but it is not fixed to "mysql". If you create a definition in sys::Sys.env (which includes environment variables, system properties, or lib/sys.props) of "sql.foo.driver=bar", then we attempt to preload the class "bar".

Relevant code is in ConnectionPeer.java in static initializer.

I am open to suggestions if we want to enhance/change.

sys.props ships with entries for mysql so when you first use SqlService, it tries to preload that driver. However, fan does not seem to ship with the mysql driver so you end up with CNFE. I tried Sys.env.remove("sql.mysql.driver") but got an error about env being readonly. I ended just modifying sys.props so I could move past that but I imagine I'd get a similar error on trying to add a prop. I didn't bother because even if I could add, it'd still fail on that missing mysql jar.

I think having repo.props supported in ${FAN_REPO} would be a very handy and simple way to override or augment those system properties, personally.

Promoted to ticket #753 and assigned to brian

really this is a couple of issues:

• probably shouldn't predefine mysql
• probably shouldn't output a warning if can't load a driver (maybe negates previous bullet)
• sys.props should really be a symbol file which works with the repo model

that last one is probably the biggest, and I didn't do that yet because there is bootstrap stuff in we use in launcher code (C/bash) that complicated things - but I think I just need to sit down and get it all squared away

Ticket resolved in 1.0.50

I made a set of changes to leverage all the new environment APIs. Now all the configuration is done via the standard "etc/sql/config.props" which leverages the standard infrastructure for config props and Env based overrides.

I also reworked how JVM class preloading is done for the drivers. Now it is configured based dialect:

// JVM drivers; these are java classnames which are loaded
// into the VM using Class.forName whenever the specified
// dialect is used:
//   {qname}.driver={classname}
sql::MySqlDialect.driver=com.mysql.jdbc.Driver

Also while I was in there I tweaked a couple APIs to use a more consistent naming convention:

SqlService.make            => defaults to GenericDialect, not MySqlDialect
SqlService.isAutoCommit    => autoCommit field
Dialect.maxTableNameLength => maxTableNameSize
Dialect.maxIndexNameLength => maxIndexNameSize
Dialect.getBlobType        => blobType
Dialect.getClobType        => clobType