Filter in 5.1.0.3294

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!

The database filter has been moved again to the session manager dialog. Solved issue #1485.

I saw this possibility but, sorry if I make a mistake, we can only choose one DB.
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.

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.

The problem with the internal db filter box was that it was a redundant feature after having solved issue #1485.

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...

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.

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 ?

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.

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?

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

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.

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) ;)

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 ;-)

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.

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 :-)

Oh, no offense meant - in case you misunderstood me - just my immediate, probably rough thoughts.

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.

Thank you, I really appreciate!