Hi,
On Jan 7, 2008, at 1:22 PM, Jess Robinson wrote:
> On Sun, 6 Jan 2008, Pedro Melo wrote:
>> On Jan 5, 2008, at 4:05 PM, Ash Berlin wrote:
>>> On Jan 5, 2008, at 11:01 AM, Jess Robinson wrote:
>>>> On Sat, 5 Jan 2008, Pedro Melo wrote:
>>>>> I was using Producer::MySQL and noticed that my boolean fields
>>>>> where
>>>>> getting generated as ENUM's.
>>>>>
>>>>> Is there any reason for this? MySQL supports BOOLEAN (converts to
>>>>> TINYINT).
>>>>>
>>>> Ah, but since when has it supported Booleans? SQL::T has been
>>>> around
>>>> since
>>>> at least mysql 3.x, so it contains some rather old assumptions
>>>> about
>>>> data
>>>> types etc.
>>>
>>> [[ These types are synonyms for TINYINT(1). The synonym BOOLEAN
>>> was added
>>> in MySQL 4.1.0. A value of zero is considered false. Non-zero
>>> values are
>>> considered true ]]
>>>
>>> There you go. So i guess some producer option to switch it back
>>> to either
>>> enum mode or to an explicity TINYINT(1) for <= v4.0.x would also
>>> be in
>>> order.
>>
>> Attached my first attempt at a patch. I don't know if I'm breaking
>> any
>> project rules, if you want some tweaks, ask away.
>
> You've missed a couple of bits, it should be something like
> "mysql-server-version", or, following what already exists for the
> parser
> side, "mysql-producer-version".
I'll use mysql-server-version. I think its better because we are
asking for the server version, not the producer version.
I used server_version because I assumed mysql was implicit in the
producer name. This way, every producer could use the same option,
for the same semantic meaning.
> For bonus points, also add some doc about it to bin/sqlt, which is
> where
> all the options are docced.
OK, I'll update that.
>> 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?
default is undef. In that case, it will generate a tinyint being that
the most compatible option.
the second version of the patch, is different:
* by default, it will generate the previous SQL, with ENUM('0', '1');
* if present and < 4.1, tinyint;
* if present and >= 4.1, boolean.
>> 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.
See second patch. If you don't specify server_version, it will
generate the previous ENUM.
If present and < 4.1, I choose to switch to tinyint to solve the
problems I had and ash documented with the ENUM choice.
> 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. We
> likely already have some features that won't work with some
> versions of
> databases that sqlt used to support.
>
> IMO we should support the commonly used/widely spread versions of
> things
> as much as possible, but, we should add some sorta comment in the
> created
> SQL to say which minimal server version it supports. (should support).
>
> Pedro, care to make those changes to this one?
Sure. I'll change:
* server_version => mysql-server-version;
* documentation in sqlt;
* default (no mysql-server-version present) will generate the old
ENUM code;
Please confirm if this is what you are expecting.
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
