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
