Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
11:00 < Marc9> http://wiki.phpmyadmin.net/pma/2015-02_Meeting 11:00 < smita786> yea .. 11:01 < Marc9> Start of team meeting 11:01 < Marc9> welcome to everyone 11:01 -!- madhuracj|2 [~firstname.lastname@example.org] has joined #phpmyadmin 11:01 < Marc9> Item 1: Bug discussion: Zero Conf 11:02 < Marc9> Everyone familiar with this feature? 11:02 < ibennetch> About 4749 where Olaf suggests first using the database `phpmyadmin`, I agree with that part. About the other one, 4754 where it's not active until visiting the associated database, I do not have a solution to this. It seems he's using an edge case that I'm not sure we need to support. 11:02 -!- madhuracj|2 [~email@example.com] has quit [Read error: Connection reset by peer] 11:02 -!- nijel-phone [~firstname.lastname@example.org] has joined #phpmyadmin 11:02 < Marc9> (In my opinion, this is a way to encourage using the configuration storage, but cannot replace completely the proper configuration in all cases) 11:02 < Marc9> Hi Michal 11:03 -!- madhuracj|2 [~email@example.com] has joined #phpmyadmin 11:03 < nijel-phone> hi 11:03 < ibennetch> Yes, i agree with what Marc9 just said 11:03 < nijel-phone> sounds reasonable 11:03 < Marc9> ibennetch, well I'm not even sure that we should be using the phpmyadmin database. This would mean more tests and more db server traffic 11:04 < ibennetch> In the case where a user doesn't have access to more than one database, it works as expected; in the case where a user has access to many databases, we should offer to create and use the `phpmyadmin` database. Aside from that, I don't see what else we should do in this case. 11:04 -!- madhuracj|2 [~firstname.lastname@example.org] has quit [Read error: Connection reset by peer] 11:04 -!- madhuracj [~email@example.com] has joined #phpmyadmin 11:04 < Marc9> Indeed, the case with just one db is well covered 11:05 < ibennetch> Sure, we want to minimize both tests and server traffic. 11:05 < _dstorm> To me, current behaviour seems good enough 11:05 < Marc9> ibennetch, so it would mean we cease to support the scenarios described in the doc? 11:06 < ibennetch> We certainly can't test on first load each database the user has access to in order to determine whether the configuration storage tables exist there, which I think is the only way to fix his second report. 11:06 < Marc9> ibennetch, what I don't like is that we don't know whether the user has access to a "phpmyadmin" db 11:07 < ibennetch> To be blunt, I don't know what is best here. We've entered an area of trying to guess what's best for most users, but can't account for every user preference and configuration scenario. 11:08 < Marc9> ibennetch, agreed 11:09 < Marc9> The problem is that if we switch again the behavior, users will be confused 11:09 < ibennetch> I just read again the three situations from the documentation and think we've covered pretty well all reasonable situations. 11:09 < nijel-phone> we really can not guess everything, users still should configure otherwise... 11:10 < ibennetch> I greatly appreciate Olaf's feedback on many issues, but think in this case that at least 4754 is not something we should fix. 11:10 < Marc9> Ok, do we firmly object to create per-db configuration storage in the case of ZeroConf ? 11:11 < ibennetch> yes 11:11 < Marc9> I know I do 11:12 < smita786> yes, me too 11:12 < nijel-phone> we should not mess up every database user has access to... 11:12 < madhuracj> Agreed 11:12 < zixtor> I agree this would duplicate things 11:12 < Marc9> We could ask the user where she wants to create the configuration storage, but since this info would only be in the session, it would not be kept 11:12 < ibennetch> Which will absolutely confuse users if they create a bookmark in `sakila` and then next session can't find it from `gis_data` 11:13 < ibennetch> About 4749, I think he has a valid point, though -- ZeroConf should attempt to create and use the `phpmyadmin` database first. I'm speaking from a user perspective; I believe Marc9 is concerned about the additional tests and server traffic which is a valid technical concern. Is there a good solution to both technical and user experience here? 11:14 < ibennetch> Or in this case, should the user simply go to the work to manually create the structure? 11:14 < Marc9> No, this feature is about automating things 11:15 < Marc9> So, the scenario would be: when ZeroConf is active, first check for a phpmyadmin db 11:16 < Marc9> (oops, first check in the current db) 11:16 < Marc9> then check for a phpmyadmin db 11:16 < Marc9> then maybe offer to create it 11:16 < Marc9> right? 11:16 < nijel-phone> sounds good 11:17 < Marc9> The first check for current db is for users having access to just one db 11:17 < Marc9> I propose to target 4.4 for this change 11:17 < madhuracj> How about initial creation? When the user navigates into a database he's offered to create table there as well as in phpmyadmin database? 11:18 -!- AlphaTech [uid35525@gateway/web/irccloud.com/x-pdrqzveygbbkmvry] has quit [Quit: Connection closed for inactivity] 11:18 < madhuracj> or create phpmyadmin database if it does not exist? 11:18 < Marc9> We should give her the choice 11:19 < Marc9> Giving the choice would mean a possible double verification on login 11:19 < ibennetch> What about when a user first logs in we try to use `phpmyadmin`? Rather than wait for the user to enter a database and check that one. I think `phpmyadmin` should take priority over the individual database. 11:20 < Marc9> ibennetch I don't think so, as more users only have access to their own db 11:20 < ibennetch> Then we should change the link to create the structure to give the user the choice for "create a new `phpmyadmin` database or use existing (____) database" 11:20 < Marc9> on shared hosting I mean 11:20 < ibennetch> Okay, that's a valid point. 11:21 < ibennetch> Most non-shared hosting users can change their configuration, so you're right that we should target the shared host users 11:22 < Marc9> Something else to add? 11:22 < nijel-phone> sounds good to me 11:23 < Marc9> Item 2, bug discussion "after creating a table" 11:23 < Marc9> After creating a table, what's best to show 11:23 < Marc9> ? 11:23 < Marc9> (without adding a new configuration directive;) ) 11:24 < Marc9> currently, the list of tables is shown 11:24 < madhuracj> I am fine with the current behavior 11:24 < zixtor> Looking at the reasoning in the user's comment, I think it should go to the new table rather than present behavior of going to db 11:24 < Marc9> I don't really mind, we cannot please everyone 11:25 < nijel-phone> I see good reasons for both... 11:25 < Marc9> Returning to the table's Structure permits to prove that creation went well 11:25 < nijel-phone> but going to the created table seems better choice to me 11:25 < Marc9> so we could return to table's Structure but reject future bug reports about this ;) 11:25 < smita786> yeah, I personally would like to go table structure page as an user 11:26 < smita786> what about giving options on create table page ? about where to go next ? 11:27 < madhuracj> @smita789 As in insert page? 11:27 < ibennetch> similar to the drop down on the insert page, I like that idea. 11:27 < Marc9> Smita, it will be a click to do on the creation page, instead of later, so it won't helpo 11:27 < Marc9> help 11:27 < Marc9> I mean, how many options to show there? 11:27 < smita786> ibennetch, yeah 11:27 < zixtor> According to the user, new table creation option is available from navi panel already.. So going into new table seems better 11:28 < smita786> by default, we can have db page 11:28 -!- nijel-phone [~firstname.lastname@example.org] has quit [Quit: AtomicIRC: The nuclear option.] 11:28 < smita786> so user might not always need to do a click if okay with db page 11:29 < Marc9> Smita, I would prefer avoiding to clutter the UI if it's not absolutely needed 11:30 < zixtor> Smita, this would add another field to choose while creating table 11:30 < Marc9> If the majority agrees that it should return to the table Structure, let's do it; anyway, going to db page is one click away 11:30 < smita786> Marc, I agree with that as well. page already hav lots of options 11:30 < smita786> I agree with going to table structure page 11:31 < Marc9> Decision made? 11:31 < madhuracj> I guess yes 11:31 < _dstorm> yes 11:31 < Marc9> Moving on 11:31 < zixtor> I agree as well 11:31 < Marc9> Item 3.1, RFE 205 11:31 < ibennetch> While we're on the topic, are we happy with the action after database creation? It seems to stay on the database page, but if we're changing the table creation we might also want to change that? 11:32 < Marc9> ibennetch, what do you suggest? 11:33 < ibennetch> We're assuming that after a user creates the table they'll want to see the structure page; so after creating a databse the user probably wants to see the database structure page instead of the list of databases. 11:33 < smita786> I think, that should go database structure .. where user is offered to create new table 11:33 < Marc9> Smita I agree 11:33 < ibennetch> Since we're changing the table we should change the database one as well 11:34 < zixtor> Agreed 11:34 < Marc9> ibennetch, can you open a ticket ? :) 11:34 < ibennetch> Sure 11:34 < Marc9> Moving on 11:34 < ibennetch> About 205, I've made a comment there already. I think it should be closed. 11:35 < madhuracj> I also think it should be closed 11:35 < Marc9> ibennetch, I also think the same after the test I did today; circular referencing can be tricky and this request is so old, it must be not so popular 11:36 < Marc9> Marked as "wont-fix" 11:36 < Marc9> Now, ticket 352 11:37 < Marc9> Can someone confirm my questionning in the ticket? 11:37 < madhuracj> This is what I understand too 11:38 < Marc9> If this is really an indirect relation, this would be tricky to implement, as there can be many ways you can be indirect 11:38 < Marc9> A B C or A B D 11:38 < Marc9> Unless we make this configurable, but it's still an edge case 11:39 < madhuracj> While this is a valid request I think it's an edge case 11:39 < ibennetch> I agree with madhuracj 11:39 < madhuracj> Indeed. Not sure whether we should spend time implementing it 11:40 < ibennetch> It sounds like it's too difficult to implement properly. 11:40 < Marc9> Other opinions? 11:41 < Marc9> Moving on 11:41 < Marc9> ticket 406 11:41 < ibennetch> I don't know what to say about this one 11:42 < Marc9> My feeling is that, being so old, it must be unpopular 11:42 < madhuracj> I think using a SET is a wrong approach here. A third table is the proper way to implement this relationship 11:42 < ibennetch> It seems the user is trying to do it wrong. 11:42 < Marc9> I agree that SET is not very relational 11:43 < Marc9> that's why I never use it ;) 11:43 < ibennetch> Yeah, madhuracj said it better than me. I'd reject this on the grounds that it's not proper technique and we don't want to allow users to mess up their data 11:44 < Marc9> Something to add? 11:44 < ibennetch> On the other hand, it's technically valid according to MySQL, so should we allow it anyway? 11:45 < ibennetch> I think no: it's the wrong approach and in 12 years there hasn't been much complaint. 11:45 < Marc9> To help the decision, it would help to have sample tables in the ticket 11:45 < Marc9> So we could ask for sample tables and mark Pending ;) 11:46 < ibennetch> Sure, fine by me 11:46 < Marc9> Done. 11:47 < Marc9> Moving on 11:47 < Marc9> ticket 260 11:47 < Marc9> edit/delete links on joined tables 11:47 < ibennetch> I think it's valid but implementing it is probably going to be difficult. Perhaps so difficult that it's not worth the time. I suggest to leave it open for now but I'm not sure when we would add this. 11:48 < Marc9> ibennetch let's try to made a decision today 11:48 < Marc9> to make 11:49 < smita786> I think it will be good to have 11:49 < Marc9> When we switched to the current behavior, 11:49 < _dstorm> Feature sounds nice.. 11:49 < Marc9> it was because of so many bug reports, and this was just for one table 11:49 -!- alisha [~email@example.com] has joined #phpmyadmin 11:50 < Marc9> The logic is complex to get right 11:50 < _dstorm> Agree with Marc 11:51 < Marc9> For example, in the past, for a table without a unique key we would build a WHERE clause based on all the columns seen in the SELECT 11:52 < Marc9> but at some point, we just gave up and the current behavior shows the "Current selection does not contain unique column...." message 11:52 < smita786> what if we have the links only when all the table in join have primary key 11:52 -!- gigo1980___ [~gigo1980@pD954DBA9.dip0.t-ipconnect.de] has joined #phpmyadmin 11:52 < smita786> otherwise it'll be very difficult 11:53 < Marc9> Smita it might work 11:53 < ibennetch> That seems the only way to reasonably do this, but even in that case is it too much to parse and 11:53 < ibennetch> handle all the variations people will try? 11:54 < Marc9> Also, what do you show to Edit such "row" ? 11:54 < madhuracj> Even with this only grid edit would work right? Since there are 2 or more tables joined for traditional edit we wouldn't know which table to go to? 11:54 < Marc9> The Insert/Edit logic is only per-table 11:54 < Marc9> I was forgetting grid-editing :) 11:55 < _dstorm> grid would be difficult too 11:55 < _dstorm> *grid editing 11:55 < ibennetch> I would only expect this grid editing here, yes. 11:55 < ibennetch> *expect this to use grid editing* 11:55 < _dstorm> because same column and row data might be there in multiple rows of result...so editing one would require to update all fields simultaneously 11:55 < Marc9> and for Delete, with the previous behavior we got complaints about deleting not the intended data 11:56 < Marc9> _dstorm good point 11:57 < Marc9> four minutes 11:57 < Marc9> So let's reject this one 11:58 < madhuracj> Fine by me 11:58 < _dstorm> Yes, we should reject it 11:59 < Marc9> (by the way, I think that this meeting was quite productive and we should discuss tricky bug reports and feature requests each month) 12:00 < smita786> Agreed :-) 12:00 < ibennetch> Yes, it was quite productive! 12:00 < Marc9> End of team meeting, thanks to all for your participation 12:00 < zixtor> I agree 12:01 < madhuracj> Bye everyone
Clone this wiki locally
Press h to open a hovercard with more details.