2015 02_Meeting_IRC_Log

11:00 < Marc9> https://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 [~kvirc@112.134.80.43] 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 [~kvirc@112.134.80.43] has quit [Read error: Connection reset by peer]
11:02 -!- nijel-phone [~yaaic@37-48-41-116.tmcz.cz] 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 [~kvirc@112.134.80.43] 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 [~kvirc@112.134.80.43] has quit [Read error: Connection reset by peer]
11:04 -!- madhuracj [~kvirc@112.134.80.43] 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 [~yaaic@37-48-41-116.tmcz.cz] 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 [~quassel@115.184.44.120] 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