distal-attribute
distal-attribute
distal-attribute
distal-attribute

Filter in 5.1.0.3294

User, date Message
Written by energiesysteme
4 years ago
Category: Feature discussion
17 posts since Wed, 24 Feb 10
Hello,

I upgraded to the version 5.1.0.3294 and I've lost the possibility to filter databases in the left tree view.

My problem is that I have lots of DB and I just want to use several at the same time. The feature was very helpful for that (filter example "db1;db67") because I only saw those 2 DB instead of more than 100!

I loved this feature.
Is there a new (convenient) way to do the same? The filter in the right panel, in my opinion, is not very convenient and with less possibilities (;, *, ...).
If not, I will downgrade to an older version.

Thank you in advance!
Written by ansgar
4 years ago
4967 posts since Fri, 07 Apr 06
The database filter has been moved again to the session manager dialog. Solved issue #1485.
Written by energiesysteme
4 years ago
17 posts since Wed, 24 Feb 10
I saw this possibility but, sorry if I make a mistake, we can only choose one DB. unhappy
Even after see the issue #1485, I don't understand where was the problem with the DB filter.
I think I will downgrade to a version which proposed the feature.
Written by ansgar
4 years ago
4967 posts since Fri, 07 Apr 06
You can speficy more than one db, separated by semicolon. Just the drop down functionality is surely not capable to give you more than one item per click.
Written by ansgar
4 years ago
4967 posts since Fri, 07 Apr 06
The problem with the internal db filter box was that it was a redundant feature after having solved issue #1485.
Written by energiesysteme
4 years ago
17 posts since Wed, 24 Feb 10
Thanks for the tip with the semicolon in the session manager.

I don't think it is redundant. You can specify several db and also want a filter on your db.
I've reinstalled the old version which is, in my sense, much more flexible!
RIP good and very convenient feature...unhappy
Written by ansgar
4 years ago
4967 posts since Fri, 07 Apr 06
Well, it was redundant in my eyes, as it enables exactly the same feature, just in a different way. It was more flexible, yes, that's why I had implemented it that way, but there were also arguments for solving issue #1485 so I made a step backwards to help users of old servers, enhance that feature with a combobox approach and hoped users will be conveniant with that way.
Written by jfalchMoney, Euro
4 years ago
385 posts since Sat, 17 Oct 09
why not
a) check for server version first after connect, then
b) offer filter box (and get data for it) only if version >=5.0 ?
according to your own version statistics, about only 10% of all users still use v4 or below; why must the other 90% be hampered by a one-size-fits-all solution ?
Written by ansgar
4 years ago
4967 posts since Fri, 07 Apr 06
Session manager lives before you connect. Connecting involves closing the session manager, so we cannot connect and get back to the session manager in case we noticed an old version. That would be totally ugly for usability reasons.

jfalch wrote: why must the other 90% be hampered by a one-size-fits-all solution ?



The non-allowed SHOW DATABASE issue is still valid in current MySQL versions, if hosters enable "skip_show_database" in their my.cnf . Please read the issue comments and tell these people their messy servers lead to hampering on your server. I don't think that's the way to go. I think getting a compromise somewhere inbetween should be ok for all - I'm not asking you to say it's perfect, just be ok with it please.

Also, I can't see any hampering for any user, the db field has just moved from after connecting to before connecting. You know how minor the differences between these approaches are, do you?
Written by energiesysteme
4 years ago
17 posts since Wed, 24 Feb 10
I read the issue #1485 and I understand the problem; this is a real problem.

"the db field has just moved from after connecting to before connecting" is a good summary, but if you have a project with lot of db and you have to work on only a few at one time, it was better before. We can't make one session manager entry for each combination and we can't use with all the db listed.
The solution is the downgrade.
That was why I loved HeidiSQL much more than MySQL Front unhappy
Written by ansgar
4 years ago
4967 posts since Fri, 07 Apr 06

energiesysteme wrote: We can't make one session manager entry for each combination


I wonder how many combinations there are?

However, I understand your argument, only that's not enough to justify a redundant filter feature. Redundance is one of the worst things to have, for both - developer and user - point of view.
Written by energiesysteme
4 years ago
17 posts since Wed, 24 Feb 10
I have about 1.000 db.
One which is the reference (I always need to have access to this db) and the others which are composed by up to 1.000 tables.
When I work on this project, I need the reference table and 2 or 3 others db (depending of the part of the project).
That's why I loved this feature.

I agree with you, redundance is a very bad thing.
In this case (maybe because it's my need), I don't think it's redundance. The session manager is for design the project perimeter and the db filter is to access to several db in the current project.
Don't worry about that, I'll survive (it's just a frustration) ;)
Written by x2A
4 years ago
14 posts since Fri, 22 May 09
No no no no no it was most certainly not a redundant feature, please do not confuse "in my usage pattern" with "in usage patterns".

Many features that have been dropped in Heidi after being judged as "redundant" are only actually redundant if one other condition is true: that you are not in the middle of doing something.

My usage pattern is such that I am mostly in the middle of doing something. There are also times where I am starting something, and slightly fewer times when I am just finishing something (eek)! But mostly, I'm in the middle of something, and as such, a huge chunk of Heidi's impressive feature set is simply inaccessible to me.

It's a great piece of software for people who have one thing to do, and never need to check anything or change anything during that process. To me, it's the best table editor and sql query executer, love it, but these new event/procedure/trigger editors? Well, they stop me from using the table editor, so I manually construct them instead. That way I get to use the query editors features like double clicking a table one left, clicking field names on the right, and the main important feature - the table viewer/editor. So the event/procedure/trigger editors are therefore usused, redundant features, which as you know, is one of the worst things to have ;-)
Written by ansgar
4 years ago
4967 posts since Fri, 07 Apr 06
The procedure editor is redundant? Probably for you, but it was one of the most wanted features by many users.

Users are indivuals, and each of them might have some slightly different workflow of using Heidi, and that's very ok. But things to be implemented need some major reception, as Heidi tries to do its best for the majority of users, not all of them. Especially for similar features maintenance effort is just higher than it would be if there was only one of them. In order to keep being agile and to keep development fun I will always decide for removing stuff when it's not required in my eyes.
Written by x2A
4 years ago
14 posts since Fri, 22 May 09
The procedure editor is redundant? ... it was one of the most wanted features

It's wanted by me too! But as I explained, I can't use it; it's modal, that's not a judgement, this is just a true thing that I am saying. I then continued down the line of reasoning you used to call a useful feature 'redundant', which resulted in me calling a different useful feature 'redundant'... but it's not my reasoning! I don't think either are redundant.

My point was about your statement, not about your software. I've never asked you to make a non-modal procedure editor, I'm a programmer, I know it'd be an effort, and I wouldn't ask you to do that just for me. Asking to be able to connect to high ports, above 32767, I was okay with, as with the report I posted today regarding the panel filter while switching databases, which to me has come up exactly once so I put 'minor' in the subject line.

The only thing I asked here was from the word "please" to the full stop (or 'period' for American), and that's not for my benefit. Descriptions of my usage patterns are there for you to bare in mind, or if you think they're not useful, ignore. I shan't be offended. I'm okay with being thought of as unique :-)
Written by ansgar
4 years ago
4967 posts since Fri, 07 Apr 06
Oh, no offense meant - in case you misunderstood me - just my immediate, probably rough thoughts.
Written by ansgar
4 years ago
4967 posts since Fri, 07 Apr 06
In case anyone didn't notice - this db filter box is now displayed again since many users have asked me to do that. See issue #2054.
Written by energiesysteme
4 years ago
17 posts since Wed, 24 Feb 10
Thank you, I really appreciate!
 

Please login to leave a reply, or register at first.