[11.0.25 Pro] - FR: syncing Formatting rules

[11.0.25 Pro] - FR: syncing Formatting rules

When adding a formatting rule to the set of rules, the rule is only added to the rule set currently selected. Having to manually sync the new rule to all the rule sets even for the same RDBMS can be quite a burden. For example, I tend to use for rule sets: the default (which is the most verbose) and three others each of which tries to compact the code to different extents. That means each new rule added or any that is changed and is required to be used in other sets as well has to be manually copied to three other rule sets. And that's only one rule. I, for one, frequently meet at least five different RDBMSs (Oracle, SQL Server, MariaDB, MySQL, SQLite) and considering that I'm on my way to include PostgreSQL into that list, creating and maintaing a consistent set of rule sets for all of those requires a rather large supply of painkillers.

It would be great if there was a fast, easy, and convenient method for syncing the rules between/to different rulesets (and RDBMSs).

For tracking purposes, this is within enhancement request #SA0037970, which is currently queued.

I was told that this is already supported. Drag and drop method can be used to copy rules between the sets. Drag from the bottom list and drop on the destination rule set in the top list.

Yes, that's what I referred to as manually copying. That works pretty well for very few RDBMSs with very few rule sets and copying very few rules, eg. two at most.

I use 5 different RDBMSs, 4 rule sets for each (and I'm fairly certain about not being unique doing so). Let's say I want to sync 3 rules everywhere. I create them in one rule set and then select one of them (because I can only have one selected at any time) and have to drag and drop it to 3 other rule sets for the same RDBMSs, and 4 times for each of the other 4 RDBMSs. That's 19 drag and drops for one rule. Then I have to repeat that for the two other rules, which blows that number to 57.

After that, I'm still not done because the drag and drop operation does not sync. It does not pop warnings about rules being overwritten, it doesn't overwrite, it merely creates a copy of the rule, and if there was already one with that name, it simply creates a duplicate. So I have to walk over the tree to check those 57 rule sets and manually disable/drop the ones they should be replacing. This reminds me of another feature request I planned posting for ages but never did until now. I've posted it here.

That's neither easy nor convenient. And it's definitely not fast. A pane with filtering on RDBMSs and ruleset names and checkboxes and syncing instead of plain copying would be comparably faster.

Thank you. I think I understand and can feel your pain. I will share your feedback with the team here.

If I may, based on all the inputs available in this support forum, I think you are pretty unique in how many things you develop and customize to make your work more efficient, you deserve all the credit for it.

	SysOp wrote:
	If I may, based on all the inputs available in this support forum, I think you are pretty unique in how many things you develop and customize to make your work more efficient, you deserve all the credit for it.

Maybe. And I know that I often overdo things. But drawing a conclusion on support forum input and activity might be a bit biased and is not entirely representative. Many of the posts accumulate several hundreds of views per reply, some of them get into thousands. I think the number of active users isn't anywhere near that. The passive (read-only :) users are the overwhelming majority and we (or at least I) haven't got any info on their use cases.

With all that said, I realize that wasting resources implementing features only a few users (or even a single one) would use is not good for anyone. After all, my goal isn't unattainable using currently available methods, it's just dishearteningly hard. But I'm persistent and I'll definitely get there once, even if I have to do hundreds of drag and drops :)

By the way, have you considered switching to a more interactive (chat-like) support forum that supports polling? A poll could help getting a clearer picture of this particular case, for example. It could also assist in assigning a more accurate business value to features, both internals and those coming from user requests.

Hi. We have found what we think is a better solution for the described issue. Instead of searching for an easy way to copy and create kind of redundant formatting rules, snippets, and so on, we will develop a new shared "area" for generic rules that can be used anywhere and across multiple rule sets and database interfaces, so it won't be necessary to copy them. Do you see any issues with that approach?

SysOp wrote:

Hi. We have found what we think is a better solution for the described issue. Instead of searching for an easy way to copy and create kind of redundant formatting rules, snippets, and so on, we will develop a new shared "area" for generic rules that can be used anywhere and across multiple rule sets and database interfaces, so it won't be necessary to copy them. Do you see any issues with that approach?

Yes, I do, but nothing that couldn't be dealt with. One example is the overriding of the shared one by a specific one. I also think the advantages would vastly outnumber the issues. It would help removing the clutter in formatting rules by drastically reducing their number. It would also make taking apart SELECT formatting rule into separate chunks a viable substitute for having an ugly, monolithic one for each RDBMS (by only overriding the relevant/different parts in different RDBMSes as needed). It's an excellent idea!

But, if you've already got some momentum, why stop there? There's another feature that could greatly benefit from using the same method. It might even be more important than formatting, as formatting is rather static compared to that one. It's snippets that could truly get some boost from this approach. Especially for those users that use them frequently and in multiple environments.

I guess this would require some nasty (nasty-ish?) reconstruction of some structures and internal operations. Do you think you could force this as an enhancement in v11 or would it be a new feature in v12?

Thank you. We're considering 3 features where sharing is a feasible option, more specifically we are including formatting rules, code snippets, and code generator. We also initially considered unit testing templates, but for the time being left it out of scope.

It's amazing, they have implemented that already; and it's pending the next maintenance version release.

When when when when when????

We don't know the release date yet. But I know the expected version number is going to be 11.2. That 's telling me, the release is expected likely within 2 months. If it were 11.3 or higher, skipping some other numbers, it would likely take longer to develop it.

Did this make it into 11.2? Or has it been postponed?

Yes, this is updated. On the Code Formatting tab, select any style in the list on the left. There is a new option on the right called Shared Formatting Style. Changing it from None to something else will share the style you select in that drop-down list with the one you have on your screen. You don't need to copy the rules. You can maintain them where there are. It enables you to define a common style (or styles), which you can share with others. For example

You define Base Style with common rules
You define Monday's Special style for rules you feel like using on Mondays. Then in that Monday's Special style you choose to have Base Style shared with it.
Now when you choose to use Monday's Special to format the code, both sets of rules are applied.
Similarly you can share Base Style with Tuesday's Special, and so on...

Similar method can be used for sharing code snippets and code generator rules across different collections.

Last edited by SysOp on Tue Jul 07, 2020 9:00 am; edited 1 time in total

Interesting. I've got questions and remarks about this.

#1 Do I understand it correctly that it works as described below
- you create a Base style you want to include in other styles and add common formatting rules there
- you create another style where you can include that previously createdBase style by selecting it it the Shared Formatting Style dropdown. I guess that means you can only include one, right?

#2 There can be tons of places for conflicts, eg. every style has other properties beyond the Formatting rule set it contains, for example SQL Dialect, Auto Indent Mode, Spacing and Wrapping, etc. How will the conflicting properties work out the winner? Which one will override the other? Let's say the Base Style has Line Length for Code Wrapping set to 120 and the current style has that set to 240. Which one will be used?

#3 What about the Keywords? Will the formatting use the merged list of the Keywords or only one of the Styles? What happens if the Keywords in the two styles conflict?

#3 If there are multiple rules for the same piece of code because it is handled in both the Base Style and the current one, how will those be applied? All of them? The first one? The last one? What defines the order?

#4 The styles have a setting called SQL Dialect that must be set to one of the dialects (it cannot be set to Common or Unknown or whatever). Will setting it to anything make any difference? I mean what happens if I set it to [i]SQL Server and then include that style in other styles having their respective setting set to some other dialect, eg. MariaDB? Will that still work?