Hi List!
I've modified the "common.lib.php3" library in order to "guess"
what should be the value of "$cfgPmaAbsoluteUri" in case the user
didn't complete it.
But I'm not sure it's a so nice stuff, since it depends on some
variables send by the server! Then if the server is not well
configured or do not fit CGI/1.1 specifications we may face "bugs"
that would be harder to find because it's easier to see
that "$cfgPmaAbsoluteUri" is empty than it was "automagically" set
with a wrong value.
That's why I require both you testings (with different servers)
and your opinions about this stuff.
Thanks in advance,
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
I think the relations table should go in the user's database. I don't
think we should get into user permissions issues. That is definitely
something MySQL should handle, not phpMyAdmin.
I'm not real familiar with the configuration scheme in phpMyAdmin, but
isn't there a way to have separate configuration options for individual
users? (So that each user can have a separate relations table?)
If it is not possible to have separate configurations per user, then the
relations table definitely belongs within each user database. (I guess it
would have to have a default name.)
Jay Davis
On Tue, Apr 30, 2002, Beck, Mike <mike.beck(a)ibmiller.de> wrote:
>
>> Unless I'm misunderstanding the question, the appropriate
>> place to manage
>> user permissions is within MySQL. You grant select access to the
>> relations table for everyone, but only the administrator gets
>> access to
>> UPDATE the relations table.
>>
>
>this won't work for ISPs - can't see them handling the relations for a few
>hundred clients databases. so there is only two possibilities:
>
>a) have the relationstable in the users database
>or
>b)
>for modifying the relationtable test the users rights on the table. i have
>written a script to modify the relationtable (without this feature) and sent
>it to marc, hope it will be in cvs as soon as he finished restructuring the
>tbl_properties page (it is suppossed to be called with a link from this
>page).
>i think the neat way to do it would be to make this script check if a user
>wants to put in links from table "a" as mastertable to test if he has e.g.
>the alterpriv for table "a".
>
>regards
>
>mike beck
>
>_______________________________________________
>Phpmyadmin-devel mailing list
>Phpmyadmin-devel(a)lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Heya all. Iv been working on a project which basically replicates alot
of phpMyAdmin functionality, and I was about 600 lines of code into the
project (nothing I know) when I thought to myself...*self*, before you
go coding all that code to fake referential integrity, lets go see if
you can use a table structure that phpMyAdmin is using...
Anyway, I decided to check out the current state of the table and here I
am.
Basically, I am thinking that since phpMyAdmin has started to pollute
the database with tables of its own that it might as well use a standard
prefix to add a few more tables to enable more features (eventually down
the road)...
In short this is what I propose (to be quickly shot down I am sure):
(BTW, alot of programs have variable table prefixes, is this really
neccecerry?)
CREATE TABLE phpMyAdmin_relationships (
id int(10) unsigned NOT NULL auto_increment,
local_key_a varchar(32) NOT NULL default '',
local_table varchar(32) NOT NULL default '',
foreign_key_a varchar(32) NOT NULL default '',
foreign_table_a varchar(32) NOT NULL default '',
local_key_b varchar(32) default NULL,
foreign_key_b varchar(32) default NULL,
foreign_table_b varchar(32) default NULL,
value_on_foreign_a_delete varchar(32) default NULL,
value_on_foreign_b_delete varchar(32) default NULL,
enable_cascade_actions enum('0','1') NOT NULL default '1',
PRIMARY KEY (id)
) TYPE=MyISAM
and two examples to clear things up a bit
INSERT INTO qdb_relationships VALUES (1, 'dr_id', 'perscriptions', 'id',
'doctors', NULL, NULL, NULL, '', NULL, '1');
INSERT INTO qdb_relationships VALUES (2, 'trainer_id', 'apointments',
'id', 'personal_trainers', 'trainee_id', 'id', 'trainiees', NULL, NULL,
'1');
The first example is for a table which lists perscriptions and their
doctors. If the matching doctor is deleted, the perscriptions id is
blanked out (blank value in value_on_foreign_a_delete.
The second example is an example of a set of appointments between
trainers and their clients. In either case, if a trainer or an employee
is deleted, the corresponding record in the local table is deleted as
well (symbolized by update value is null)
enable_cascade_options can be set to 0 for testing purposes, or if you
only want to create a link to help you quickly navigate around in
phpmyadmin
What do you think? Allows both many to one and many to many
relationships...
Additional things that im planning to add in my project but would love
to be implemented in phpMyAdmin 3.0 and in the schema sooner...
tbl_users, tbl_usergroups, tbl_groupmembership, tbl_columns, etc for
managing different levels of access to phpMyAdmin all the way down to
specific record locking if db designers include a phpMyAdmin_owner field
or something like that
Any thoughts, comments? Im thinking some of this is probably already
slightly out of the scope of phpMyAdmin, although you guys have been
doing an increadible job of filling out the current scope of the project
and it has been creeping out in its features recently, so maby such a
drastic expansion could be planned for to allow it to commence in a
planned and orderly fashion?
If not id settle for a schema so my app could play friendly phpMyAdmin
and some extra features like the cascading updates :)
> Unless I'm misunderstanding the question, the appropriate
> place to manage
> user permissions is within MySQL. You grant select access to the
> relations table for everyone, but only the administrator gets
> access to
> UPDATE the relations table.
>
this won't work for ISPs - can't see them handling the relations for a few
hundred clients databases. so there is only two possibilities:
a) have the relationstable in the users database
or
b)
for modifying the relationtable test the users rights on the table. i have
written a script to modify the relationtable (without this feature) and sent
it to marc, hope it will be in cvs as soon as he finished restructuring the
tbl_properties page (it is suppossed to be called with a link from this
page).
i think the neat way to do it would be to make this script check if a user
wants to put in links from table "a" as mastertable to test if he has e.g.
the alterpriv for table "a".
regards
mike beck
Please don't kill me if this is not the right place to post my ideas for
the new version but I don't know where to place it instead.
1. Default query
My thought is that when you have for example a table t_persons and you
place a query in the bookmark-table with the same name as the table that
this query should be executed instead of the "select * ..." when you
click "browse"
2. Execute button (or link) for bookmark-table
That means that I think it would be nice if you browse the bookmark table
that you get an additional button or link in each line to execute the
defined query
Regards
Igor
>If you like it, I'll commit it to our CVS tree.
I do (like it) :)
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi list,
I changed the design of the links on the top of the new tbl_properties
pages.
As we get more and more links there, I compressed it a bit to support our
800x600 pixel users :o)
In addition to this, I changed the color of the 'drop' link to red to show
the danger of this command.
If you like it, I'll commit it to our CVS tree.
Happy testing,
Alexander
Hi again!
>But I think that a small click on a [Structure] link is
>easily done.
Right :)
>So there could be a [Main] page with:
>- the links :)
>- the Query box
>- the bookmark stuff
>- "Insert from a textfile". (?)
OK but in my opinion these links should now be displayed at
the top of all the pages you can reach with them.
Maybe we should add a frame for them?
About "Insert from a textfile", see my previous reply ;)
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi Marc & List!
>I think the "add new field" really belongs to the same page
>where the structure is displayed.
OK, that's right. Sorry but you have to move it back since
I've done the changes yesterday :o
>I would prefer a separate page named [Options] where we put
>- Table comments
>- Table type
>- The new controls for feature request 441716: Ability to
> tweak MyISAM better
>- Any new options that will be needed for other table types.
That's a good idea. +1 for me.
>Maybe not my icons but better icons...
As you want to but they should be there quickly IMHO: with the
left menu of Moz. on a 1024*768 screen I've got to scroll to see
all menu items right now.
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi devs,
Let's discuss the game plan for 2.3.0.
- Merge the patches currently from the tracker
- Merge/code the new db-based config
- code some new features (I will be working on MyISAM options, and InnoDB support, + the Relation
stuff
- interface: it's about time we split the pages: db_detail and tbl_properties.
Suggestions for the tbl_properties split
----------------------------------------
- generally, we move large sections of tbl_properties to seperate pages
- an [Export] link at the top, calling a page with the "view dump" dialog
- an [Attributes] link, for Alter table order by, Comments, Table type, and the upcoming MyISAM
options (and InnoDB)
- an [Operations] link, for Rename, Move, Copy, Maintenance (4 items), Flush, Drop (maybe Insert
data from a file)
- a [Structure] link, to show Fields and Indexes, + the Add field
- (not sure about this) by default, users clicking on a table name would see the familiar Browse,
Select, Insert, Empty, Drop + the 4 new links, at the top, but not the structure. I find that most
of the time, I don't want to see the structure, I just want to type queries, use bookmarks, and be
able to use the other main links.
- a right/top-frame for the links?
Please comment.
--
Marc Delisle
