oqgraph-dev team mailing list archive

[Antony T Curtis <atcurtis@xxxxxxxxx>]

There is no way to turn off the auto-casting. MySQL is actually a weakly typed database, unlike all the other SQL RDBMS.

Regards,
Antony

On 2 May, 2013, at 2:28 am, Andrew McDonnell wrote:

> Actually that shouldnt be too hard:
> at the point the table is opened, detect what it is and change accordingly.
> This is a clean upgrade path.
> 
> If they have a int latch, the legacy code will work, and we can print a warning
> If they have the  char latch, the new code will work.  If they try and select
> an int with a varchar latch, nothing will be returned.  Ideally I would rather
> return a warning but there is no way to detect this -
> do you know if it is possible to turn off autocast?
> 
> On 29/04/13 02:58, Antony T Curtis wrote:
>> Personally, I believe that it would be simply better for the ::create method
>> to validate the table structure and for ::open to check and alter behaviour
>> accordingly. So, if the latch column is declared as an integer column, handle
>> it as such. If it is an enum, check that it makes sense otherwise if it's a
>> varchar, do the string to type manual mapping.
>> 
>> Just my 2¢
>> 
>> Antony
>> 
>> On Apr 28, 2013 2:54 AM, "Andrew McDonnell" <bugs@xxxxxxxxxxxxxxxxxxx
>> <mailto:bugs@xxxxxxxxxxxxxxxxxxx>> wrote:
>> 
>>    Hiya
>> 
>>    sorry its been a while
>> 
>>    Recap:
>>    - I have a branch up on LP with my changes to support the string-based latch
>>    - it also interprets numeric values passed to the latch to support
>>    backwards compatibility
>>    - however if the numeric latch is specified as a number instead of a
>>    string (e.g. select ... where latch=3   vs.  select ... where latch='3' )
>>    it fails
>> 
>>    In recent conversation with Arjen:
>>>> Although there was some discussion around what to do
>>>> about legacy instances because of the problem with numeric autocast?
>>> 
>>> Is it that the server doesn't use the correct (indexed) access method
>>    because of the cast?
>>> Show me a trace (do use the oqgraph-dev list)
>>> If that is the case, then perhaps returning an error if a numeric latch
>>    is seen might be the solution.
>> 
>> 
>>    Following is a big dump of test and trace, you probably wont have enough
>>    context so I am bracing for clarifying questions :-)
>> 
>>    But basically I dont yet have enough understanding of storage engine guts
>>    to know how to hook a query before the query optimiser bypasses us
>> 
>> 
>>    I think the more important question, is how to handle (not) breaking
>>    existing deployments.
>> 
>> 
>> 
>>    After all, new databases can just be forced to use the new syntax.
>> 
>> 
>>    But if any existing db is upgraded, our code will need to properly handle
>>    the legacy form on upgrade....
>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
> <snipped>
> 
> -- 
> Mailing list: https://launchpad.net/~oqgraph-dev
> Post to     : oqgraph-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~oqgraph-dev
> More help   : https://help.launchpad.net/ListHelp