oqgraph-dev team mailing list archive

[Andrew McDonnell <bugs@xxxxxxxxxxxxxxxxxxx>]

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>