oqgraph-dev team mailing list archive

[Andrew McDonnell <bugs@xxxxxxxxxxxxxxxxxxx>]

Hi all,

I guess in the absence of further comment, I should safely go ahead and
implement this?

When I get these changes finished I'll push again  up to my branch at
bzr+ssh://bazaar.launchpad.net/~andymc73/maria/10.0-oqgraph3-varchar

After which I might need some handholding as to how to get it back into the
main branch - or is that only something you can do?

--Andrew


On 02/05/13 18:58, 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>
>