List:Internals« Previous MessageNext Message »
From:Martijn Tonies Date:June 3 2005 2:16pm
Subject:Re: MySQL 5: views and definition storage
View as plain text  
Hello Ingo,

> Am Freitag, den 03.06.2005, 13:47 +0200 schrieb Martijn Tonies:
> ...
> > ALTER VIEW is already implemented (according to the documentation).
> >
> > Store the original string in a BLOB field of a system table.  Anything
> > beyond
> > "AS". Store other properties in other fields.
>
> But how should the output of a SHOW CREATE VIEW look like after an ALTER
> VIEW?

There are different things here.

I think we can agree on the fact that everything after AS defines the actual
view. The "view body" as we can call it.

This is the part that should be stored "as is" in any case. Obviously,
restore
it for an ALTER VIEW -> this defines a new view body.

> If there are comments related to a dropped column, how can we know that
> we have to drop the comment too?

A different storage mechanism would store the complete CREATE VIEW
mechanism. This could get annoying for tool developers, like myself, who'd
rather see stored comments (actual comments, no "inline" comments) in
a separate mechanism.

> What if the creator did not specify every column on a separate line, but

Doesn't matter. Most systems have a mechanism to retrieve (view) columns.

> adds a comment which is realated to one of the columns only?

That depends -- in code comment, in the view body, should be stored with
the view body. Anything before the AS part of the CREATE VIEW can
be ignored. I've never heard people complaining about that.

>I mean how
> should the output look like when one of these columns is dropped?

See above.

> What if the creator uses a very weird format for his CREATE VIEW and
> ALTER VIEW? We would end up with a new parser that mainatins pointers
> into the string so that we know which parts of the string have to be
> replaced by the ALTER command. And still we would not necessarily get
> the comments right.
>
> So I personally think that we need to generate the output and cannot
> retain comments.
>
> And yes. To be clear, I want to say that everybody agrees that the
> format of the string is ugly and should be improved. The problem is
> known. But it is still a matter of priority.
>
> What about storing the commented string in some table yourself?

Most systems, if not all, provide a way to store comments for each object,
a table, a stored procedure (so does MySQL for SPs), a column. These
are stored in dictionary tables and can be retrieved via special commands
or SQL statements.

However, "source code" comments should be retained in procedure bodies
or view bodies.

btw, when creating a Stored Procedure via the command line tool for MySQL,
comments are filtered out.

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com

Thread
MySQL 5: views and definition storageMartijn Tonies1 Jun
  • Re: MySQL 5: views and definition storageMartijn Tonies3 Jun
    • Re: MySQL 5: views and definition storageIngo Strüwing3 Jun
    • Re: MySQL 5: views and definition storageSanja Byelkin24 Jun
  • Re: MySQL 5: views and definition storageMartijn Tonies3 Jun
    • Re: MySQL 5: views and definition storageIngo Strüwing3 Jun
  • Re: MySQL 5: views and definition storageMartijn Tonies3 Jun
    • Re: MySQL 5: views and definition storageIngo Strüwing3 Jun
  • Re: MySQL 5: views and definition storageMartijn Tonies3 Jun
    • Re: MySQL 5: views and definition storageJim Winstead3 Jun
  • Re: MySQL 5: views and definition storageMartijn Tonies3 Jun
    • Re: MySQL 5: views and definition storageJim Winstead3 Jun
  • Re: MySQL 5: views and definition storageMartijn Tonies24 Jun