-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi list,
There's a small change that I'd like to see in 2.6.1, but I don't have the time to implement it.
MySQL 4.1 supports adding comments on column level. Afaik, phpMyAdmin only supports its own column comments, but not MySQL's native ones.
On top of that, I think that column comments don't fit into the relation overview. I'd rather move the interface to the table structure editor.
This should be the preferred way to perform this operation.
Comments?
Regards,
AMT
Alexander M. Turek a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi list,
There's a small change that I'd like to see in 2.6.1, but I don't have the time to implement it.
MySQL 4.1 supports adding comments on column level. Afaik, phpMyAdmin only supports its own column comments, but not MySQL's native ones.
On top of that, I think that column comments don't fit into the relation overview. I'd rather move the interface to the table structure editor.
This should be the preferred way to perform this operation.
Comments?
Regards,
Hi Alexander,
The "internal" column comments interface is _already_ available in the table structure editor. So I guess it's just a matter of removing it from the relation view... The only advantage of having it in the relation view is to quickly add column comments to many columns. I think we could remove this "feature".
For the 4.1 column commenting, yes it would be a welcome addition. I wonder if we should do like in the relation view, where we offer both internal relations and InnoDB relations. Some people might already have internal column comments and we have to show them, but they want to add native 4.1 comments. We could even do the switch ourselves.
Please comment on this, then I could find some time this week to implement it.
Marc
Hi Marc!
For the 4.1 column commenting, yes it would be a welcome addition. I wonder if we should do like in the relation view, where we offer both internal relations and InnoDB relations. Some people might already have internal column comments and we have to show them, but they want to add native 4.1 comments. We could even do the switch ourselves.
I'd vote for using the 4.1 internal structure, if available instead of our internal one. We'd need to abstract all calls to fetching comments to be replacable with a SQLquery to get column comments. There's much depending on column comments (like "show table aliases in left frame" option and embedding comments in SQL dump), so I don't think a user should be able to enter differing comments in our infrastructure or the MySQL one. I also don't think it's necessary to offer the user a switch to use either infrastructure.
Or does anyone think there'll be a need that a user wants to store his comments in PMA DB instead of MySQL 4.1?
Regards, Garvin.
Hi
On Monday 29 November 2004 12:08, Garvin Hicking wrote:
I'd vote for using the 4.1 internal structure, if available instead of our internal one. We'd need to abstract all calls to fetching comments to be replacable with a SQLquery to get column comments. There's much depending on column comments (like "show table aliases in left frame" option and embedding comments in SQL dump), so I don't think a user should be able to enter differing comments in our infrastructure or the MySQL one. I also don't think it's necessary to offer the user a switch to use either infrastructure.
Or does anyone think there'll be a need that a user wants to store his comments in PMA DB instead of MySQL 4.1?
I'd say same for relation stuff :-). Why do we provide both ways to define them?
Michal Čihař a écrit:
Hi
On Monday 29 November 2004 12:08, Garvin Hicking wrote:
I'd vote for using the 4.1 internal structure, if available instead of our internal one. We'd need to abstract all calls to fetching comments to be replacable with a SQLquery to get column comments. There's much depending on column comments (like "show table aliases in left frame" option and embedding comments in SQL dump), so I don't think a user should be able to enter differing comments in our infrastructure or the MySQL one. I also don't think it's necessary to offer the user a switch to use either infrastructure.
Or does anyone think there'll be a need that a user wants to store his comments in PMA DB instead of MySQL 4.1?
I'd say same for relation stuff :-). Why do we provide both ways to define them?
Because AFAIK, foreign key constraints are only supported in InnoDB.
Marc
Garvin Hicking a écrit:
Hi Marc!
For the 4.1 column commenting, yes it would be a welcome addition. I wonder if we should do like in the relation view, where we offer both internal relations and InnoDB relations. Some people might already have internal column comments and we have to show them, but they want to add native 4.1 comments. We could even do the switch ourselves.
I'd vote for using the 4.1 internal structure, if available instead of our internal one. We'd need to abstract all calls to fetching comments to be replacable with a SQLquery to get column comments.
Garvin, we already have PMA_getComments($db, $table). Did you find someplace not using this call to fetch comments?
There's much depending on column comments (like "show table aliases in left frame" option and embedding comments in SQL dump), so I don't think a user should be able to enter differing comments in our infrastructure or the MySQL one. I also don't think it's necessary to offer the user a switch to use either infrastructure.
By "switch" I meant this: suppose someone already has comments in pmadb. Does he have to reenter them in the MySQL structure?
Or does anyone think there'll be a need that a user wants to store his comments in PMA DB instead of MySQL 4.1?
Regards, Garvin.
Hi Marc!
Garvin, we already have PMA_getComments($db, $table). Did you find someplace not using this call to fetch comments?
I haven't looked at the codebase specifically, so I just wanted to make sure it's abstracted at the "root" level :)
By "switch" I meant this: suppose someone already has comments in pmadb. Does he have to reenter them in the MySQL structure?
Oh, that's a very important thing, I nearly forgot. Maybe it would be the best way to make getComments() fetch both PMA-data and MySQL 4.1 data. I don't know aobut the performance impact though, but that way we could use data from both worlds". We could even emit a warning if MySQL 4.1 is found AND there is comment data fetched from the PMADB: "Please use migrate your PMAdb data to the new MySQL 4.1 structure using [link]this command[/link]. Any future stored comments are saved in MySQL 4.1 format only".
Or something like that...? Maybe even automatically migrate any PMAdb data into MySQL 4.1 on first call...
Regards, Garvin.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi there,
Garvin Hicking wrote:
By "switch" I meant this: suppose someone already has comments in pmadb. Does he have to reenter them in the MySQL structure?
Oh, that's a very important thing, I nearly forgot. Maybe it would be the best way to make getComments() fetch both PMA-data and MySQL 4.1 data. I don't know aobut the performance impact though, but that way we could use data from both worlds". We could even emit a warning if MySQL 4.1 is found AND there is comment data fetched from the PMADB: "Please use migrate your PMAdb data to the new MySQL 4.1 structure using [link]this command[/link]. Any future stored comments are saved in MySQL 4.1 format only".
This would be the way to go, imho. And on top of that, we could safely remove the field for column comments from create_tables_4.1.2+.sql.
Regards,
AMT
Garvin Hicking a écrit:
Hi Marc!
Garvin, we already have PMA_getComments($db, $table). Did you find someplace not using this call to fetch comments?
I haven't looked at the codebase specifically, so I just wanted to make sure it's abstracted at the "root" level :)
By "switch" I meant this: suppose someone already has comments in pmadb. Does he have to reenter them in the MySQL structure?
Oh, that's a very important thing, I nearly forgot. Maybe it would be the best way to make getComments() fetch both PMA-data and MySQL 4.1 data. I don't know aobut the performance impact though, but that way we could use data from both worlds". We could even emit a warning if MySQL 4.1 is found AND there is comment data fetched from the PMADB: "Please use migrate your PMAdb data to the new MySQL 4.1 structure using [link]this command[/link]. Any future stored comments are saved in MySQL 4.1 format only".
Or something like that...? Maybe even automatically migrate any PMAdb data into MySQL 4.1 on first call...
Regards, Garvin.
OK I am working on this whole feature.
Marc
Marc Delisle a écrit :
Garvin Hicking a écrit:
Hi Marc!
Garvin, we already have PMA_getComments($db, $table). Did you find someplace not using this call to fetch comments?
I haven't looked at the codebase specifically, so I just wanted to make sure it's abstracted at the "root" level :)
By "switch" I meant this: suppose someone already has comments in pmadb. Does he have to reenter them in the MySQL structure?
Oh, that's a very important thing, I nearly forgot. Maybe it would be the best way to make getComments() fetch both PMA-data and MySQL 4.1 data. I don't know aobut the performance impact though, but that way we could use data from both worlds". We could even emit a warning if MySQL 4.1 is found AND there is comment data fetched from the PMADB: "Please use migrate your PMAdb data to the new MySQL 4.1 structure using [link]this command[/link]. Any future stored comments are saved in MySQL 4.1 format only".
Or something like that...? Maybe even automatically migrate any PMAdb data into MySQL 4.1 on first call...
Regards, Garvin.
OK I am working on this whole feature.
Marc
Just wanted to mention that I am still working on this, as time permits...
Marc
-
Alexander M. Turek -
Garvin Hicking -
Marc Delisle -
Marc Delisle
-
Michal Čihař