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" <b...@andrewmcdonnell.net >> <mailto:b...@andrewmcdonnell.net>> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~oqgraph-dev > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~oqgraph-dev Post to : oqgraph-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~oqgraph-dev More help : https://help.launchpad.net/ListHelp
