Hi,
On Jan 7, 2008, at 11:22 AM, Dave Howorth wrote:
> Pedro Melo wrote:
>> On Jan 6, 2008, at 3:23 PM, Darren Chamberlain wrote:
>>
>>> * Pedro Melo <melo at simplicidade.org> [2008/01/06 13:29]:
>>>> 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.
>>>>
>>>> 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.
>>> This changes the existing default behavior, does it? I vote that it
>>> default to the current behavior, just so that there's no surprises.
>>
>> I understand your point, but I think that Producer::MySQL should
>> produce the best SQL for the current GA release of MySQL.
>>
>> We should mention the change in the release notes and move on.
>
> I agree with Darren and disagree with you. It is more important to
> avoid
> breaking people's existing code than it is to provide shiny new
> features
> by default. Technically savvy users can easily get the improved
> behaviour by setting options. Innocent users - perhaps not even more
> than dimly aware that SQL::Translator is used by the system they're
> using - should not be forced into debugging sessions.
My idea is that if we don't move forward, we will always be
explaining what options to set for new users. If somebody today uses
SQLTranslator, it should have the best SQL generated.
I would not call support for boolean shiny new feature :).
But if this is the consensus, I'll redo my patch to keep things as
they where (and go back to ENUM ('0', '1') and use the new stuff if
and only if you set the appropriate server_version variable.
this sounds ok?
> I'm not an expert, but AFAICT from a quick scan of the manual,
> MySQL is
> in any case just changing BOOLEAN to TINYINT in any case, so
> there's no
> operational benefit, just a conceptual one.
The problem is that the previous code was generating ENUM ('0', '1').
> SQL::Translator has a history of somewhat tricky installs & upgrades,
> IMHO. It's not desirable to add to that :)
As I said, I think SQL::Translator would be better if by default it
generates the best SQL for the current version of each database, but
I also understand your point of view, so I'll redo my patch.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
-------------------------------------------------------------------------
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
