Jess Robinson wrote: >> I'm created a producer_args key, server_version, that you can set to 3.23, >> or 4.0, or any other version of MySQL. This influences the field type that >> we generate for boolean fields. > > I couldn't quite figure out, what does this default to, if the user > doesn't supply a version at all?
That's the whole point. If the user (i.e. some random module that calls SQLT but hasn't itself been updated) doesn't supply a version, then SQLT should provide the existing behaviour not a new behaviour. Pedro stated the opposite in the third sentence below. >> Pre-4.1, MySQL producer will generate a tinyint. 4.1 and above we will >> generate a boolean. if no version is given, we generate boolean. > > Any reason not to let the <4.1 output remain as it was? Then it's > somewhat backcompat. > As for the general backcompat discussion: In general backcompat is nice, > when it comes to API/syntax/option args etc etc. I don't think it applies > to upgrading the SQL we output to cope with new versions of databases. I don't believe the issue is to do with database versions. It's to do with second- or third-party client code that hasn't been modified to cope with the new SQLT release. For example, just because I rerun SQLT to regenerate some of my application code doesn't mean I'm going to rebuild a database running on some other server. > We likely already have some features that won't work with some > versions of databases that sqlt used to support. Those would be what are called 'regression bugs' then :) Especially if you don't already know about them and have documented them. Cheers, Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- sqlfairy-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlfairy-developers
