Nando Dessena wrote:
>>>I'm not sure about it. If it's not a huge amount of data, then we're
> M> Define huge. :)
> in the thousands.
Ok, in that case, let start with config and see how it works.
>>>But should it really be per-database? Is there no
>>>advantage in having it cross database boundaries?
> M> There is if you have databases with the same structure. But even then I
> M> find it more distrupting then helpful.
> Here's why I thought about that: in my current main job I use 90% of
> the time the same database structure. Dozens of databases, all with
> the same structure. The remaining 10% I use another database
> structure, with just two or three instances. Two database structures
> in total, and I'd find it a nice feature just to be able to share the
> history among databases. Perhaps you could just have a config option
> like "statementHistoryGranularity" which can be global, per-server,
> The code to handle it would be similar to that of the
> metadata item property frame, which is not much complex and doesn't
> add clutter. The option could default to per-database. How does it
Ok. I'll add it to SQL editor options in Preferences:
Share SQL statement history
(o) between all databases
( ) between databases on same server
( ) between databases with same display name
( ) don't share (each database has its own)
The last one would be default, although I think I'll be using the third
one myself. I have some 7-8 servers registered, and similar databases
exist on various servers. On one server, I rarely have the same databases.
> BTW, you'll also need a "statementHistorySize" option.
Yep, that too.
> You could encapsulate the circular buffer in a suitable class that
> handles the interaction with the config.
Yep. I plan to call it History or StatementHistory. It would have
methods like: next(), previous(), first(), last(), isAtEnd(),