In MemSQL, you cannot drop and recreate or in some cases alter an object or column if it is referenced by another object such as a view without dropping and recreating it as well. There are many reasons that one may need to perform these changes, e.g., change a table type, key, or column data type. However, as references increase over time, it becomes exceedingly difficult to manage these changes, especially if there are nested references, where you have to drop and recreate the views in a specific order. How can object changes with references be managed? One thought I had is to only access tables through a pass-through view such that you can temporarily point them to a copy of the object while you make your changes, which allows you to avoid changing every object with a reference (other objects would only reference the pass-through view).
For 6.8, I know that a view does pin down objects that it references and this can be cumbersome for application development and evolution. In 7.0, you can have SCHEMA_BINDING turned on or off for each view definition. The default will be off. So a view will no longer pin down objects that it references by default. Stored procedures already have schema binding off.
The new 7.0 CREATE VIEW docs are here:
1 Like
I wasn’t aware of that. That’s great news! It’ll make managing changes much simpler. Thanks.